Wireless WPA2 enterprise Radius authentication
Has anyone gotten Freeradius 2.x and LDAP (OpenLDAP, FDS, etc...) to properly authenticate users? I get the following in my radius log Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 0 via TLS tunnel) Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 14 cli 78e400881f19) This is driving me crazy. I can authenticate users from the radius serve to ldap but not from the access point to radius to ldap If anyone has gotten it to work please post the example config files that you used. Im open to answer any questions that you may have about my configs. Access point using WPA2-Enterprise >> Freeradius 2.x >> 389-DS(Fedora LDAP) -- View this message in context: http://freeradius.1045715.n5.nabble.com/Wireless-WPA2-enterprise-Radius-auth... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 10/26/2010 03:59 AM, midnightsteel wrote:
Has anyone gotten Freeradius 2.x and LDAP (OpenLDAP, FDS, etc...) to properly authenticate users?
I get the following in my radius log
Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 0 via TLS tunnel) Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 14 cli 78e400881f19)
This is driving me crazy. I can authenticate users from the radius serve to ldap but not from the access point to radius to ldap
If anyone has gotten it to work please post the example config files that you used. Im open to answer any questions that you may have about my configs.
Access point using WPA2-Enterprise>> Freeradius 2.x>> 389-DS(Fedora LDAP)
Yes, people have used LDAP to authenticate 802.1x. Run the server in debug mode (I should get a keyboard macro to type this) and look at the output: radiusd -X | tee logfile ...as you make an authentication attempt. Chances are if you read that debug output (as suggested in the README) you'll see the problem. If not post the full debug output here. In brief: 1. Your ldap server needs to contain the password hash(es) appropriate for your method of authentication(s) - or better yet the plaintext - and the freeradius binddn must be able to see them 2. The attribute names should match ldap.attrmap, or you should update is You said "FreeRadius 2.x". That's a bit vague. What is the actual version?
I'm running freeradius 2.1.9-1. I will run the debug test when I get home later The funny thing is, it could be just 1 small setting that I missed. This is a pain. I have a Windows Vista/7 clients connecting to a cisco e3000 wireless router (WPA2 Enterprise) authenticating to > freeradius 2.1.9-1 > authenticating to 389-DS-1.2.1-1(fedora directory service). DO you have any sample configs that work with a setup as mentioned above? From: Phil Mayers [via FreeRadius] [mailto:ml-node+3236704-1217559822-142716@n5.nabble.com] Sent: Tuesday, October 26, 2010 4:41 AM To: midnightsteel Subject: Re: Wireless WPA2 enterprise Radius authentication On 10/26/2010 03:59 AM, midnightsteel wrote:
Has anyone gotten Freeradius 2.x and LDAP (OpenLDAP, FDS, etc...) to
properly
authenticate users?
I get the following in my radius log
Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 0 via TLS tunnel) Auth: Login incorrect: [wii/<via Auth-Type = EAP>] (from client access port 14 cli 78e400881f19)
This is driving me crazy. I can authenticate users from the radius serve to ldap but not from the access point to radius to ldap
If anyone has gotten it to work please post the example config files that you used. Im open to answer any questions that you may have about my configs.
Access point using WPA2-Enterprise>> Freeradius 2.x>> 389-DS(Fedora LDAP)
Yes, people have used LDAP to authenticate 802.1x. Run the server in debug mode (I should get a keyboard macro to type this) and look at the output: radiusd -X | tee logfile ...as you make an authentication attempt. Chances are if you read that debug output (as suggested in the README) you'll see the problem. If not post the full debug output here. In brief: 1. Your ldap server needs to contain the password hash(es) appropriate for your method of authentication(s) - or better yet the plaintext - and the freeradius binddn must be able to see them 2. The attribute names should match ldap.attrmap, or you should update is You said "FreeRadius 2.x". That's a bit vague. What is the actual version? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html _____ View message @ http://freeradius.1045715.n5.nabble.com/Wireless-WPA2-enterprise-Radius-auth entication-tp3236494p3236704.html To unsubscribe from Wireless WPA2 enterprise Radius authentication, click here <http://freeradius.1045715.n5.nabble.com/template/TplServlet.jtp?tpl=unsubsc ribe_by_code&node=3236494&code=bWlkbmlnaHRzdGVlbEBtc24uY29tfDMyMzY0OTR8LTEyN Dk0NTUwNjY=> . -- View this message in context: http://freeradius.1045715.n5.nabble.com/Wireless-WPA2-enterprise-Radius-auth... Sent from the FreeRadius - User mailing list archive at Nabble.com.
On 26/10/10 13:10, midnightsteel wrote:
I’m running freeradius 2.1.9-1. I will run the debug test when I get home later
The funny thing is, it could be just 1 small setting that I missed. This is a pain.
I have a Windows Vista/7 clients connecting to a cisco e3000 wireless router (WPA2 Enterprise) authenticating to > freeradius 2.1.9-1 > authenticating to 389-DS-1.2.1-1(fedora directory service).
DO you have any sample configs that work with a setup as mentioned above?
The default FreeRadius configs are appropriate.
Hi Phil. Thanks for responding. I've attached the debug out. If anyone else wants to jump in feel free. -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of Phil Mayers Sent: Tuesday, October 26, 2010 12:13 PM To: freeradius-users@lists.freeradius.org Subject: Re: Wireless WPA2 enterprise Radius authentication On 26/10/10 13:10, midnightsteel wrote:
I'm running freeradius 2.1.9-1. I will run the debug test when I get home later
The funny thing is, it could be just 1 small setting that I missed. This is a pain.
I have a Windows Vista/7 clients connecting to a cisco e3000 wireless router (WPA2 Enterprise) authenticating to > freeradius 2.1.9-1 > authenticating to 389-DS-1.2.1-1(fedora directory service).
DO you have any sample configs that work with a setup as mentioned above?
The default FreeRadius configs are appropriate. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Maurice James <midnightsteel@msn.com> wrote:
[ldap] looking for check items in directory... [ldap] userpassword -> User-Password == "{SSHA}5wzxRoUPX/rLkS9hY1HztczPN8u5m/dGDzKvdg=="
This will not work. You need a cleartext password. This SSHA-Hash is only good for PAP, any challenge response method like MSCHAPv2 won't function with this.
[mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] Told to do MS-CHAPv2 for MJames with NT-Password [mschap] FAILED: No NT/LM-Password. Cannot perform authentication. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject
And this is the result --> reject. Grüße, Sven. -- Sig lost. Core dumped.
How do I do it? Radius to ldap works no problem Wireless to radius to ldap does not -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of Sven Hartge Sent: Wednesday, October 27, 2010 3:47 PM To: freeradius-users@lists.freeradius.org Subject: Re: Wireless WPA2 enterprise Radius authentication Maurice James <midnightsteel@msn.com> wrote:
[ldap] looking for check items in directory... [ldap] userpassword -> User-Password == "{SSHA}5wzxRoUPX/rLkS9hY1HztczPN8u5m/dGDzKvdg=="
This will not work. You need a cleartext password. This SSHA-Hash is only good for PAP, any challenge response method like MSCHAPv2 won't function with this.
[mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] Told to do MS-CHAPv2 for MJames with NT-Password [mschap] FAILED: No NT/LM-Password. Cannot perform authentication. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject
And this is the result --> reject. Grüße, Sven. -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 10/27/2010 06:18 PM, Maurice James wrote:
How do I do it?
You were kindly given the answer previously by Maurice. But just to reinforce please review the compatibility information here: http://deployingradius.com/documents/protocols/compatibility.html The client is sending mschap, look at the table above, what are the valid password formats for mschap? What authentication mechanisms are valid with SSHA? So you basically have 3 choices: 1) Store cleartext passwords in ldap 2) Store nt hash in ldap 3) Don't support mschap clients Or if AD is available as your ldap use ntlm_auth with AD to support mschap.
Maurice James<midnightsteel@msn.com> wrote:
[ldap] looking for check items in directory... [ldap] userpassword -> User-Password == "{SSHA}5wzxRoUPX/rLkS9hY1HztczPN8u5m/dGDzKvdg=="
This will not work. You need a cleartext password. This SSHA-Hash is only good for PAP, any challenge response method like MSCHAPv2 won't function with this.
[mschap] No Cleartext-Password configured. Cannot create LM-Password. [mschap] No Cleartext-Password configured. Cannot create NT-Password. [mschap] Told to do MS-CHAPv2 for MJames with NT-Password [mschap] FAILED: No NT/LM-Password. Cannot perform authentication. [mschap] FAILED: MS-CHAP2-Response is incorrect ++[mschap] returns reject
And this is the result --> reject.
-- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
Maurice James <midnightsteel@msn.com> wrote:
How do I do it?
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 And no, there is _no_ way to use _any_ CHAP method using an encrypted or hashed password.
Radius to ldap works no problem
Yes, because this most definitely uses PAP as authentication method, which works with hashed/encrypted passwords.
Wireless to radius to ldap does not
This is because the windows wireless supplicant can only use MSCHAPv2 (or ans SSL cert) to authenticate. This is a FAQ item, I suggest you to read the documentation on the website again. http://wiki.freeradius.org/index.php/FAQ#PAP_authentication_works_but_CHAP_f... Grüße, Sven. -- Sig lost. Core dumped.
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. 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. 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. 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. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
I will give it another try. I've been trying to the last hour to get the clear text password policy to stick to a user. Every time I run the radius debug I see hashed value passed from LDAP. I have to search online for the instructions on how to get 389-ds server to use clear text. Thanks for all the help and advice all. This is one of the most responsive lists that I have ever been a member of -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of John Dennis Sent: Wednesday, October 27, 2010 7:44 PM To: FreeRadius users mailing list Cc: Sven Hartge Subject: Re: Wireless WPA2 enterprise Radius authentication 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. 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. 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. 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. -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 10/27/2010 07:56 PM, Maurice James wrote:
I will give it another try. I've been trying to the last hour to get the clear text password policy to stick to a user. Every time I run the radius debug I see hashed value passed from LDAP. I have to search online for the instructions on how to get 389-ds server to use clear text. Thanks for all the help and advice all. This is one of the most responsive lists that I have ever been a member of
389-ds has most all the features I mentioned. The Administrators Guide is your friend. 389-ds doc can be found here: http://directory.fedoraproject.org/wiki/Documentation#389_Documentation The Administrators Guide can be found here: http://www.redhat.com/docs/manuals/dir-server -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/
OK gentlemen. I finally found the option for password storage (by the way the search function on the documentation website SUCKS!! Lol) So far that was the only change that I made According to Sven, my problem was here (> [ldap] userpassword -> User-Password == "{SSHA}5wzxRoUPX/rLkS9hY1HztczPN8u5m/dGDzKvdg==") LDAP is no longer using that hash to store passwords. It's using CLEAR instead of SSHA I will let you know what happens...... -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of John Dennis Sent: Wednesday, October 27, 2010 8:54 PM To: FreeRadius users mailing list Subject: Re: Wireless WPA2 enterprise Radius authentication On 10/27/2010 07:56 PM, Maurice James wrote:
I will give it another try. I've been trying to the last hour to get the clear text password policy to stick to a user. Every time I run the radius debug I see hashed value passed from LDAP. I have to search online for the instructions on how to get 389-ds server to use clear text. Thanks for all the help and advice all. This is one of the most responsive lists that I have ever been a member of
389-ds has most all the features I mentioned. The Administrators Guide is your friend. 389-ds doc can be found here: http://directory.fedoraproject.org/wiki/Documentation#389_Documentation The Administrators Guide can be found here: http://www.redhat.com/docs/manuals/dir-server -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of John Dennis Sent: Wednesday, October 27, 2010 8:54 PM To: FreeRadius users mailing list Subject: Re: Wireless WPA2 enterprise Radius authentication On 10/27/2010 07:56 PM, Maurice James wrote:
I will give it another try. I've been trying to the last hour to get the clear text password policy to stick to a user. Every time I run the radius debug I see hashed value passed from LDAP. I have to search online for the instructions on how to get 389-ds server to use clear text. Thanks for all the help and advice all. This is one of the most responsive lists that I have ever been a member of
389-ds has most all the features I mentioned. The Administrators Guide is your friend. 389-ds doc can be found here: http://directory.fedoraproject.org/wiki/Documentation#389_Documentation The Administrators Guide can be found here: http://www.redhat.com/docs/manuals/dir-server -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On 28/10/10 11:48, Maurice James wrote:
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice
The "ldap" module isn't running at all in the "inner-tunnel" virtual server AFACIT. You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/10/10 11:48, Maurice James wrote:
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice
The "ldap" module isn't running at all in the "inner-tunnel" virtual server AFACIT.
You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel
And it looks like the old "Windows does not respond to Access-Challenge" problem, also documented in the FAQ. Grüße, S° -- Sig lost. Core dumped.
On 28/10/10 12:34, Sven Hartge wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
On 28/10/10 11:48, Maurice James wrote:
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice
The "ldap" module isn't running at all in the "inner-tunnel" virtual server AFACIT.
You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel
And it looks like the old "Windows does not respond to Access-Challenge" problem, also documented in the FAQ.
Erm... no it doesn't.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/10/10 12:34, Sven Hartge wrote:
Phil Mayers<p.mayers@imperial.ac.uk> wrote:
On 28/10/10 11:48, Maurice James wrote:
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice
The "ldap" module isn't running at all in the "inner-tunnel" virtual server AFACIT.
You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel
And it looks like the old "Windows does not respond to Access-Challenge" problem, also documented in the FAQ.
Erm... no it doesn't.
Yes, you are (of course) right. Must be the lack of coffee on my side. Grüße, S! -- Sig lost. Core dumped.
Thanks all I will try that tonight -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of Sven Hartge Sent: Thursday, October 28, 2010 7:34 AM To: freeradius-users@lists.freeradius.org Subject: Re: Wireless WPA2 enterprise Radius authentication Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 28/10/10 11:48, Maurice James wrote:
OK here are the logs from the latest test. As you will see the password is stored in cleartext, but still no dice
The "ldap" module isn't running at all in the "inner-tunnel" virtual server AFACIT.
You need to enable ldap in /etc/raddb/sites-enabled/inner-tunnel
And it looks like the old "Windows does not respond to Access-Challenge" problem, also documented in the FAQ. Grüße, S° -- Sig lost. Core dumped. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
OK gentlemen, After many sleepless nights I finally got it working. I was almost in tears (lol) but its done. Full authentication and authorization for a mix of Windows7 x64/Vista x64 clients using WPA2 Enterprise, Freeradius, 389-DS(Fedora Directory Services). I will post the configs in a follow-up email. Special thanks to the following John Dennis Sven Hartge Phil Mayers Thanks guys MCITP Enterprise + Server GIAC Security Leadership Certification (GSLC) -----Original Message----- From: freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org [mailto:freeradius-users-bounces+midnightsteel=msn.com@lists.freeradius.org] On Behalf Of John Dennis Sent: Wednesday, October 27, 2010 8:54 PM To: FreeRadius users mailing list Subject: Re: Wireless WPA2 enterprise Radius authentication On 10/27/2010 07:56 PM, Maurice James wrote:
I will give it another try. I've been trying to the last hour to get the clear text password policy to stick to a user. Every time I run the radius debug I see hashed value passed from LDAP. I have to search online for the instructions on how to get 389-ds server to use clear text. Thanks for all the help and advice all. This is one of the most responsive lists that I have ever been a member of
389-ds has most all the features I mentioned. The Administrators Guide is your friend. 389-ds doc can be found here: http://directory.fedoraproject.org/wiki/Documentation#389_Documentation The Administrators Guide can be found here: http://www.redhat.com/docs/manuals/dir-server -- John Dennis <jdennis@redhat.com> Looking to carve out IT costs? www.redhat.com/carveoutcosts/ - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
John Dennis <jdennis@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.
participants (5)
-
John Dennis -
Maurice James -
midnightsteel
-
Phil Mayers -
Sven Hartge