Wireless WPA2 enterprise Radius authentication

[Sven Hartge]

John Dennis <jdennis at redhat.com> wrote:
> On 10/27/2010 07:11 PM, Sven Hartge wrote:

>> You need a password in the clear in your LDAP directory, not hashed. I use a
>> different (self defined) attribute in my LDAP directory to do this and
>> use ldap.attrmap to map this attribute (called gifb-NetzPassword in my
>> schema) to the required RADIUS-Attribute-Name:
>>
>> checkItem       Cleartext-Password              gifb-NetzPassword

> Sven knows this but probably just forgot to mention this. No matter
> which ldap attribute you choose to store the clear text password in
> make sure it is absolutely locked down with LDAP ACI's (Access
> Controls).  Consult your LDAP documentation for the exact syntax since
> it tends to vary with different servers. The ACI should permit only
> the LDAP administrator and the radius user (the special user account
> assigned exclusively to the radius *server*) to access the password
> attribute.

Yes, of course. Every attribute which contains anything used as a
password or -phrase should be locked down strictly.

While SSHA hashes are rather safe if exposed (unless the password is
something like "bunny123"), other hashes are not. Be careful with
lmpassword or ntpassword, as those hashes are used directly within
windows and should be treated the same as a cleartext password.

> You may additionally provide an extra level of protection if some one 
> gets access to the actual disk files (or backup's) of the LDAP store by 
> asking your ldap server to reversibly encrypt the attribute used to 
> store the cleartext password. Not all LDAP servers have this feature but 
> many do.

While nice to have, my argument would be: if anyone gets direct access
to the backend database of your LDAP server, you are hosed anyway.

> Finally, many people would argue it's never a good idea to store 
> cleartext passwords under any circumstance. There is much validity to 
> that argument and you should give it careful consideration.

Correct. 

Because of this and the overall lower security of any permanently stored
credentials in any of the subsystems of Windows, the password management
web-tool used by "my" users to change their passwords enforces a
different NetPassword than the normal password (or master password).

> Another option besides storing cleartext is to use a multivalued LDAP
> attribute with different hashes, including the nt hash. But whether
> you go the cleartext route or the multivalued password attribute route
> you'll have to get your users to renter their passwords so you can
> generate the hashes. Consult your LDAP documentation, many LDAP
> servers can be configured when storing a password to generate a
> variety of hashes and then throw the cleartext away leaving only the
> specified hashes in LDAP.

Unfortunately not every LDAP implementation allows a multi-valued
UserPassword attribute. But the correct solution, whether to use a
different attribute or a multi-valued one is clearly outside of the
scope of this mailinglist.

Last statement: beware of magic! Some implementations (LDAP servers
_and_ client libraries) tend to do something magic with values of
some attributes. slapcat (and a simple base64 decoder) is your friend.

Grüße,
S°

-- 
Sig lost. Core dumped.