SLES 10 RC3 breaks our admin users...

We use LDAP for authentication, and we create several administration
accounts for uid 0, so that the admins can each have their own files, and
for accountability of who has accessed uid 0 on a system.
 
SLES 10 will not allow these users to log in. The messages we're seeing are
as follows:

R0141265:~ rpn01$ ssh root_rpn@emperor
Password: 
Permissions on the password database may be too restrictive.

Password: 

Other accounts can log in as normal via LDAP, and root can log in via local
authentication. The uid 0 accounts do show up in "getent passwd".

How can I configure pam / LDAP to allow the additional uid 0 accounts to

nix.robert@mayo.edu wrote:

> We use LDAP for authentication, and we create several administration
> accounts for uid 0, so that the admins can each have their own files, and
> for accountability of who has accessed uid 0 on a system.

This is a new restriction (or security feature?) of pam_unix2. 
pam_unix2 calls other pam_modules (like e.g. pam_ldap) only if the uid 
of the user it != 0.

> SLES 10 will not allow these users to log in. The messages we're seeing
> are as follows:
> 
> R0141265:~ rpn01$ ssh root_rpn@emperor
> Password:
> Permissions on the password database may be too restrictive.
> 
> Password:
> 
> Other accounts can log in as normal via LDAP, and root can log in via
> local authentication. The uid 0 accounts do show up in "getent
passwd".
> 
> How can I configure pam / LDAP to allow the additional uid 0 accounts to
> log in and access the system?

As a workaround you can configure pam_ldap "by hand" in 
the /etc/pam.d/common-* files. Instead of using pam_ldap through pam_unix2 
(this is how YaST sets it up).

> nix.robert@mayo.edu wrote:
> 
>> We use LDAP for authentication, and we create several administration
>> accounts for uid 0, so that the admins can each have their own files,
and
>> for accountability of who has accessed uid 0 on a system.

Just out of curiosity, have you considered a sudo approach instead? Your
current system only gives you logged-in level accountability, sudo gives
you per-command accountability, plus you can restrict access to certain
commands for certain users (great for web admins who only need to
restart the web server occasionally but don't need access to rm -rf),
all of which can be pulled from LDAP instead of the /etc/sudoers file.
Plus your admins don't work as root all the time, so if one of them
accidentally does rm -rf .* hoping to just wipe out a folder in their
home directory, they don't hose the entire system.

I don't see how the admins can each have their own files, when everyone
with uid 0 is treated as the same user and hence can see each others
files, and the name mapping isn't preserved, it'll just show as whatever
comes back first in the NSS UID->Name resolution (usually root since its
a local user). NSS would be the exception to this since it uses trustees
instead of POSIX rights, but you said you're running SLES10.

Linuxjoe's approach should work, I'm just suggesting an alternative :)

-- 
Justin Grote
Novell Support Connection Sysop
Network Architect

Justin Grote [SysOp] wrote:

Darn acronym collisions...

> it'll just show as whatever
> comes back first in the NSS UID->Name resolution 
This NSS is Name Service Switch

> NSS would be the exception to this since it uses trustees
> instead of POSIX rights, but you said you're running SLES10.
This NSS is Novell Storage Services :)


-- 
Justin Grote
Novell Support Connection Sysop
Network Architect

> > nix.robert@mayo.edu wrote:
> > 
> >> We use LDAP for authentication, and we create several
administration
> >> accounts for uid 0, so that the admins can each have their own
files, and
> >> for accountability of who has accessed uid 0 on a system.
> 
> Just out of curiosity, have you considered a sudo approach instead? Your
> current system only gives you logged-in level accountability, sudo gives
> you per-command accountability, plus you can restrict access to certain
> commands for certain users (great for web admins who only need to
> restart the web server occasionally but don't need access to rm -rf),
> all of which can be pulled from LDAP instead of the /etc/sudoers file.
> Plus your admins don't work as root all the time, so if one of them
> accidentally does rm -rf .* hoping to just wipe out a folder in their
> home directory, they don't hose the entire system.
> 
> I don't see how the admins can each have their own files, when everyone
> with uid 0 is treated as the same user and hence can see each others
> files, and the name mapping isn't preserved, it'll just show as whatever
> comes back first in the NSS UID->Name resolution (usually root since
its
> a local user). NSS would be the exception to this since it uses trustees
> instead of POSIX rights, but you said you're running SLES10.
> 
> Linuxjoe's approach should work, I'm just suggesting an alternative :)
> 
> -- 
> Justin Grote
> Novell Support Connection Sysop
> Network Architect
> JWG Networks


Actually, all the users can have their own files, since it is the line in
the "virtual passwd file" that controls your home directory, and this
is
processed as the username, not the uid. So I can have a home directory in
/home/rpn, someone else can have a home directory in /home/pjs, and root
can have a home directory in /root.

sudo is likely the proper way of handling this, but that "bucks
tradition",
and makes SuSE Linux different than RedHat, AIX and Solaris. This solution
was chosen long before I got here, and works on all other Unix-based
platforms, including SuSE SLES 8.

I would think that a radically different approach to security, even of uid
0 users, should have been announced and planning allowed for before
implementation. This was accepted as a bug in SuSE SLES 9, and a workaround
was provided until it could be fixed. Now, the "fix" is to make the
bug a