how disable shadow map

[Brian J. Murrell]

Hi,

I want to disable the shadow map, and specifically, stop the passwd map
from returning "x" in the password field.  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.

Or maybe I am just barking completely up the wrong tree.

Thots?
b.

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.

Regards,
Buchan

[guillomovitch]

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).

--
BOFH excuse #399:

We are a 100% Microsoft Shop.

[Howard Chu]

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/

[Brian J. Murrell]

On Fri, 2009-10-23 at 15:26 +0100, Buchan Milne wrote:
>
> Do you need any shadow functionality?

Don't think so, nope, given that my authentication is handled by
kerberos.

> If not, just remove ldap from the shadow
> line in /etc/nsswitch.conf .

Ahhh.  If only it were that simple.  Of course I tried this and it's
that particular action that makes pam_unix's account action fail access.
The reason is that regardless of whether ldap is listed
in /etc/nsswitch.conf's shadow configuration or not, the passwd map
provided by nss_ldap still contains an "x" in the password field.

That "x" is what directs pam_unix to try to do shadow checks for the
account, and when the account is not found in the shadow map, pam_unix
fails the account action.

What needs to happen is that nss_ldap needs to stop presenting the
passwd entries with "x" in the password field if the shadow map is
undesired.

> Don't give nss_ldap access to the userPassword attribute.

And do you think that will prevent nss_ldap from presenting the password
field in the password map with a "x"?  I'm willing to try it.  What
configuration changes do you suggest?  It's been a while since I
originally set this up and would have to go refresh my aged memory on
what to do exactly.

> There is no reason
> to expose password hashes ...

In fact there are not even hashes in the userPassword attribute as LDAP
is not used at all for authentication.

> 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.

I don't enforce password and account expiry but I would imagine kerberos
handles this for me.

b.

On Fri, 23 Oct 2009, Brian J. Murrell wrote:

> > If not, just remove ldap from the shadow line in /etc/nsswitch.conf .
>
> Ahhh.  If only it were that simple.  Of course I tried this and it's that
> particular action that makes pam_unix's account action fail access.

Sorry, I wasn't paying attention to the beginning of this thread, so I
don't recall what OS you're using. Linux variants of pam_unix support the
"broken_shadow" option:

       broken_shadow
           Ignore errors reading shadow information for users in the
           account management module.

Which I think will do exactly what you want, if you're running Linux.


--
Paul B. Henson  |  [phone]  |  http://www.csupomona.edu/~henson/
Operating Systems and Network Analyst  |  henson@...
California State Polytechnic University  |  Pomona CA 91768

[Brian J. Murrell]

On Fri, 2009-10-23 at 20:16 -0700, Paul B. Henson wrote:

>
> Sorry, I wasn't paying attention to the beginning of this thread, so I
> don't recall what OS you're using. Linux variants of pam_unix support the
> "broken_shadow" option:
>
>        broken_shadow
>            Ignore errors reading shadow information for users in the
>            account management module.
>
> Which I think will do exactly what you want, if you're running Linux.

Indeed, it does and I tested that before posting.  But my distro
(Ubuntu) maintainer reports that not having shadow map entries when the
password is "x" is just broken (which given what I have read, I agree)
and I tend to think they will likely refuse to use such hacks and insist
that the breakage be fixed instead.

I'm starting to feel like I'm pissing up a rope with regard to the basic
bug here though.

b.

[Brian J. Murrell]

[ Hrm.  Gabor's message doesn't seem to have been copied to the list
despite being sent there.  I will reply to the list in any case as that
was his intention.  ]

On Sat, 2009-10-24 at 10:24 +0200, Gabor Gombas wrote:

> It seems you do not want any of the functionality of pam_unix.

Ahhh.  But I do, for any accounts that might be in the local /etc/passwd
and /etc/shadow files.  I just don't want it for accounts that would
come from Kerberos/LDAP.

> Then why
> do you use it?

Per above.

b.

[Brian J. Murrell]

On Wed, 2009-10-21 at 12:12 -0400, Brian J. Murrell wrote:
> Hi,
>
> I want to disable the shadow map, and specifically, stop the passwd map
> from returning "x" in the password field.

This is in fact quite simple to do, on a user-by-user basis even.

> 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;
>     }

This above code snippet is really what led me to the solution.

One simply removes (if it exists, which it should if your passwd entry
is "x") the shadowAccount object class from the LDAP record (which your
nss_ldap is configured to map to the passwd map) for users which you
don't want shadow information available.  The "x" in the password field
of the passwd entry changes to a "*" once this is done and there is no
entry in the shadow map any more.

Cheers,
b.

[Douglas E. Engert]

Brian J. Murrell wrote:

> On Fri, 2009-10-23 at 20:16 -0700, Paul B. Henson wrote:
>> Sorry, I wasn't paying attention to the beginning of this thread, so I
>> don't recall what OS you're using. Linux variants of pam_unix support the
>> "broken_shadow" option:
>>
>>        broken_shadow
>>            Ignore errors reading shadow information for users in the
>>            account management module.
>>
>> Which I think will do exactly what you want, if you're running Linux.
>
> Indeed, it does and I tested that before posting.  But my distro
> (Ubuntu) maintainer reports that not having shadow map entries when the
> password is "x" is just broken (which given what I have read, I agree)
> and I tend to think they will likely refuse to use such hacks and insist
> that the breakage be fixed instead.

Well then set the userPassword attributes to "{crypt}NP"
as I described on 10/21. pam_unix will not complain,
and since you are using pam_krb5 for authentication this works
fine with our Ubuntu systems.

>
> I'm starting to feel like I'm pissing up a rope with regard to the basic
> bug here though.
>
> b.
>

--

  Douglas E. Engert  <DEEngert@...>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  [phone]

[Brian J. Murrell]

On Mon, 2009-10-26 at 09:50 -0500, Douglas E. Engert wrote:
> Well then set the userPassword attributes to "{crypt}NP"
> as I described on 10/21. pam_unix will not complain,

I'm not so sure of this.  But as I posted to this thread a few days ago,
the real solution is to remove the shadowAccount object class from
records you don't want shadow information made available for.

b.