samba - Dec 2005 - getpwnam fails on ldap

Hi all (excuse my poor english): 

I have a samba PDC on a network with 100 machines and 200 users. Everything
worked fine with FC2 and samba 3.0.14a, but a hd crash decided me to update
system to FC4.
I can see now, in the logs file "User jon in passdb, but getpwnam() fails!
when an user try to log in. On XP I can not login neither add new machine to
domain.

My pass backend is ldap://localhost
When I do "getent passwd"  I get all users, files and ldap.  When I do
"net user" I get the complete users list. When joining a machine to
domain, the machine account is created on ldap by add machine script ( I use
smbldap-tools), but can not join actually to domain. Also, ntlm_auth works
without problems.

I used the "getpwnam " system call on a simple C program and works
fine.

Winbind works fine.

When I add the "getent passwd" output to /etc/passwd, users can login
with no problems again, but now getent duplicate users.

Samba versions was both 3.0.14a, on FC1 and FC4.

Any idea for solving this situation?

Thank you in advance
Ppablo

Today, WebMaster wrote:
> I have a samba PDC on a network with 100 machines and 200 users. Everything
worked fine with FC2 and samba 3.0.14a, but a hd crash decided me to update
system to FC4.
> I can see now, in the logs file "User jon in passdb, but getpwnam()
fails! when an user try to log in. On XP I can not login neither add new machine
to domain.
I have noticed the same issue here, that only came to light as I started 
deleting user entries from the files (passwd, shadow, group) as part of 
the migration process.  What is more frustrating is that the server that 
has the master ldap server works fine, but the slave instance is the one 
that has the problems described above, yet both run identical binaries 
(same RPMS installed).

samba 3.0.14a
nss_ldap 220
pam_ldap 169
glibc 2.2.5
openldap 2.2.24

tom.

Today, tom burkart wrote:
> I have noticed the same issue here, that only came to light as I started 
> deleting user entries from the files (passwd, shadow, group) as part of the
> migration process.  What is more frustrating is that the server that has
the
> master ldap server works fine, but the slave instance is the one that has
the
> problems described above, yet both run identical binaries (same RPMS 
> installed).
I have patched samba-3.0.14a/source/lib/util_pw.c:getpwnam_alloc(111) to 
return the actual errno that is set by sys_getpwnam() and it is 2 (no such 
file or directory).
Yet "getent passwd | grep <username>" returns the entry from the
ldap
directory.  The only problem I have found is that "getent shadow | grep 
<username>" returns a "<username>:x:::::::0" entry
(ie cannot access
shadow info).  All these commands are run as root so this should not be an 
issue.  But this seems to clear samba of being at fault and seems to point 
at nss_ldap.  I am somewhat guessing so I could be wrong here.

Anyway, it is now after hours and I can run tests as required so I am 
calling for ideas as to what to test next.

tom.

El Martes, 6 de Diciembre de 2005 09:35, tom burkart
escribi?:
> getent shadow
Well, when I do getent shadow I get:

moran:x:12037::99999:7:::0
moran:x:13122:0:99999:7:::
(second from files)

My temporal solution is to modify adduser script and add machine script to do
something like:
smbldap-useradd -m "$1"
UID=$(id -u $1)
useradd -u $UID -g 513 "$1"

and similar for machines

I will go on looking whats wrong.

On Dec 7, WebMaster wrote:
> Well, when I do getent shadow I get:
> moran:x:12037::99999:7:::0
> moran:x:13122:0:99999:7:::
> (second from files)
Yours has the same problem.  It does not return the encrypted password for 
some reason and that is why it fails.  I guess the main search area is 
glibc and nss_ldap.

tom.

On 12/6/05, tom burkart <samba@aussec.com> wrote:
> Yet "getent passwd | grep <username>" returns the entry
from the ldap
> directory.  The only problem I have found is that "getent shadow |
grep
> <username>" returns a "<username>:x:::::::0"
entry (ie cannot access
> shadow info).  All these commands are run as root so this should not be an
> issue.  But this seems to clear samba of being at fault and seems to point
> at nss_ldap.  I am somewhat guessing so I could be wrong here.
Did you make sure to set rootbinddn in /etc/ldap.conf and the root
password in /etc/ldap.secret?  Otherwise, getent shadow runs as an
unprivileged user, even as root.  Did you check permissions on
/etc/ldap.secret (should be mode 0600)?

Josh Kelley

El Jueves, 8 de Diciembre de 2005 15:53, Josh Kelley
escribi?:
> Did you make sure to set rootbinddn in /etc/ldap.conf and the root
> password in /etc/ldap.secret?  Otherwise, getent shadow runs as an
> unprivileged user, even as root.  Did you check permissions on
> /etc/ldap.secret (should be mode 0600)?
Ooops, I had 0644 for  /etc/ldap.secret. May it be the problem? I have to wait 
monday for having access to XP machines, now I only can get ssh access.

I can not understand why, if I copy the user data to /etc/passwd from ldap, 
(not /etc/shadow ) the user can log in, and when I delete the user 
from /etc/passwd I get a getpwnam failure. But I can use usrmgr.exe and 
smbclient works  with the user data in ldap only, with no warning.

I have kerberos running and have a DNS sever (with AD zones) in the same linux 
machine.

Thank you
PPablo

--