[nssldap] Question about getspnam/getpwnam and ldap
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[nssldap] Question about getspnam/getpwnam and ldap
- From: "Markus Moeller" <huaraz [at] moeller.plus.com>
- To: nssldap [at] padl.com
- Cc: ldap-nis [at] padl.com
- Subject: [nssldap] Question about getspnam/getpwnam and ldap
- Date: Wed, 9 Jan 2008 13:03:07 -0000
Hi,
I am looking into replacing NIS with LDAP and came to a point where I still
need to support getspnam/getpwnam for password checks as I have legacy
applications which can not be changed.
The question I have is how rfc 2307 is and should be enforced as I noticed
differences between Linux and Solaris. The rfc says:
userPassword values which do not adhere to this syntax MUST NOT be
used for authentication. The DUA MUST iterate through the values of
the attribute until a value matching the above syntax is found. Only
if encryptedpassword is an empty string does the user have no
password. DUAs are not required to consider encryption schemes which
the client will not recognize; in most cases, it may be sufficient to
consider only "crypt".
Firstly does/should getspnam enforce "userPassword values which do not
adhere to this syntax MUST NOT be used for authentication" by rejecting
userpassword entries which don't follow rfc 2307 or is it up to the
application since the rfc states "DUAs are not required to consider
encryption schemes which the client will not recognize; in most cases, it
may be sufficient to consider only "crypt"." too (assuming getspnam in
nss_ldap is the DUA) ? Solaris seems to enforce it in getspnam whereas
Linux doesn't. Also Windows 2003 R2 uses unixuserpassword (this entry can be
synchronised with the Kerberos password in AD and is therefore preferred)
which does not follow rfc2307 as it contains the hash without {crypt}.
The rfc states also:
A DUA MAY utilise the attributes in the shadowAccount class to
provide shadow password service (getspnam() and getspent()). In such
cases, the DUA MUST NOT make use of the userPassword attribute for
getpwnam() et al, and MUST return a non-matchable password (such as
"x") to the client instead.
I noticed on Linux that provides the user with both the userpassword in
getpwnam and in getspnam. Is that against RFC 2307 ? Does this mean a
getpwnam call need internally do a getspnam call to check if a password is
provided before returning to the application ?
Thank you
Markus
- [nssldap] Question about getspnam/getpwnam and ldap,
Markus Moeller