Are Reversibly Encrypted Passwords safe, and Why isn't it working when enabled for a user?

Question

In my event log, when my router tries to use Radius to authetnicate I get the following:

"""The user could not be authenticated using Challenge Handshake Authentication Protocol (CHAP). A reversibly encrypted password does not exist for this user account. To ensure that reversibly encrypted passwords are enabled, check either the domain password policy or the password settings on the user account. """

However, I enabled that for the account I am using in the User's Properties in AD. Is there some other place this needs to be enabled, or maybe I have to wait for it to replicate or restart a service (Other than the Radius one)? The IAS server is the same machine as a domain controller, and I made the change on that machine, so I would think it would take effect right away.

Also, just how unsafe is it to "reversibly encrypted passwords" ?

Edit:
I should also probably say why I am doing this in case there is a better way. I am setting up a Cisco router to by an endpoint for Client-Initiated L2TP/IPSec tunnels. I want to authenticate against AD, so if there is a better way to handle the authentication please do let me know :-) Ideally, I could still use the built-in Windows VPN Client.

Answer 1

Microsoft's TechNet page on this (here) basically says:

"Storing passwords using reversible encryption is essentially the same as storing plaintext versions of the passwords. For this reason, this policy should never be enabled unless application requirements outweigh the need to protect password information."

Answer 2

mh's link is spot on - once something is stored in a way that it can be recovered it's should be considered no better than plaintext. As it is implemented in AD enabling reversible encryption means that anyone (or anything) with Domain Admin rights can decrypt passwords because they have access to the global LSA secret which is the only part of the process that is used that is secret in any sense, everything else involved can be read from the AD by anyone or is contained in a DLL that can be manipulated\reverse engineered.

From an attack perspective if someone has Domain Admin rights it's already game over but from an internal security perspective it also means that Domain Admins can decrypt passwords into the original plain text which is not good. If nothing else I wouldn't want to be facing a security investigation where the key evidence was event log entries showing a user logging in and out using a password that technically I could know if I wanted to.

There is an interesting set of blog entries by Niels Teusink on the subject starting here.

There are many better alternatives in terms of authentication (X.509 Certs, One Time Password Tokens, Smart Cards ..) but whether you can use them or not depends on your application and the client system the users need to use. If you have full control of the environment you should be able to find a solution that allows you to avoid using them but implementing them properly may be costly and your users may find them inconvenient.

Edited following your update I'd suggest using AD Integrated Certificates, it will be a bit of work but the end result is solid and you can reuse the capability for lots of other things.

Answer 3

Why it wasn't working was apparently because the password has to be reset. I was able to do this via Active Directory.

Also, it seems I can configure the router and the Radius server to use ms-chap-v2 which doesn't require that I store the passwords with reversible encryption.