lists.arthurdejong.org
RSS feed

Re: [nssldap] how disable shadow map

[Date Prev][Date Next] [Thread Prev][Thread Next]

Re: [nssldap] how disable shadow map

Guillaume Rousse wrote:

Buchan Milne a écrit :

On Wednesday, 21 October 2009 17:12:09 Brian J. Murrell wrote:

Hi,

I want to disable the shadow map,


Do you need any shadow functionality? If not, just remove ldap from the shadow
line in /etc/nsswitch.conf .


and specifically, stop the passwd map
from returning "x" in the password field.


Don't give nss_ldap access to the userPassword attribute. There is no reason
to expose password hashes ...


I use kerberos for
authentication here and thus have no use for shadow, and having the "x"
in the passwd map without a shadow map screws up pam_unix as it thinks
that shadow information should be available and kacks when it cannot
find it.

I noticed from a quick browse of the code:

if (_nss_ldap_oc_check (e, "shadowAccount") == NSS_SUCCESS)
   {
       /* don't include password for shadowAccount */
       if (buflen<  3)
        return NSS_TRYAGAIN;

       pw->pw_passwd = buffer;
       strcpy (buffer, "x");
       buffer += 2;
       buflen -= 2;
     }
   else
     {
       stat =
        _nss_ldap_assign_userpassword (e, ATM (LM_PASSWD, userPassword),
                                &pw->pw_passwd,&buffer,&buflen);
       if (stat != NSS_SUCCESS)
        return stat;
     }

but given that I have no "nss_map_objectclass shadowAccount ..." lines
in my /etc/ldap.conf file, I must be running into some default behaviour
I need to override.


If you need other shadow functionality (e.g. password expiry), use ppolicy
instead. If you need account expiry, I don't know if there are other options.

Unfortunatly, setting scheduled password expiration date in ppolicy is
not possible, see ITS 6084:
http://www.openldap.org/its/index.cgi/Development?id=6084;selectid=6084

And relying on an operational attribute for it isn't a good idea anyway.

The only solution I know currently to schedule account termination
(either by password or account expiration)
expiration is to use shadowAccount, and it only works for pam.

On the other hand, kerberos is supposed to support principal AND
password expiration. I guess it may be used from either authentication
or authorisation stage of pam, and also for direct ldap authentication
if ldap server BIND operation is delegated to kerberos (through smbkrb5
overlay or SASL).
All of this is going to be supported in the next revision of the ppolicy spec. The OpenLDAP ppolicy overlay will be updated accordingly a short while after the new draft is published. (Should just be a few days away, I just need to collect some of the latest feedback on the current revision and merge it in...) 

--
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/