[Samba] Re: Need help with IDMAP storage in LDAP using Winbind

[Kristof Bruyninckx]

Hi, I removed the entry for "cn=manager,dc=thales,dc=be" and checked
with ldapmodigy if I could change the existing NIS users, which seems to
still work.

Now I added a user called Admin , output from slapcat :

dn: ou=People,dc=thales,dc=be
ou: People
description: All Nis people
objectClass: organizationalUnit
structuralObjectClass: organizationalUnit
entryUUID: 15579caa-c053-1029-82d3-9e2135f77083
creatorsName: cn=Manager,dc=thales,dc=be
createTimestamp: 20050923075459Z
entryCSN: 20050923075459Z#000001#00#000000
modifiersName: cn=Manager,dc=thales,dc=be
modifyTimestamp: 20050923075459Z

dn: uid=root,ou=Idmap,dc=thales,dc=be
structuralObjectClass: account
entryUUID: 1d5990e8-c053-1029-82d4-9e2135f77083
creatorsName: cn=Manager,dc=thales,dc=be
createTimestamp: 20050923075512Z
uid: root
cn: Admin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword:: secret
shadowLastChange: 13041
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 0
gidNumber: 0
homeDirectory: /root
gecos: root
entryCSN: 20050927142003Z#000001#00#000000
modifiersName: cn=Manager,dc=thales,dc=be
modifyTimestamp: 20050927142003Z

And then added the access permissions inside slapd.conf.

access to attr=userPassword
        by self write
        by anonymous auth
        by dn.base="cn=Admin,dc=thales,dc=be" write
        by * none
access to *
        by self write
        by dn.base="cn=Admin,dc=thales,dc=be" write
        by * read

and also changed the ldap admin in samba to :

ldap admin dn = cn=Admin,dc=thales,dc=be


Now when I restart the winbind daemons he is still complaining about the
dn entry: 
 
[2005/09/27 17:05:43, 1] lib/smbldap.c:another_ldap_try(951)
  Connection to LDAP server failed for the 15 try!
[2005/09/27 17:05:44, 2] lib/smbldap.c:smbldap_open_connection(630)
  smbldap_open_connection: connection opened
[2005/09/27 17:05:44, 2] lib/smbldap.c:smbldap_connect_system(790)
  failed to bind to server ldap://127.0.0.1 with
dn="cn=Admin,dc=thales,dc=be" Error: Invalid credentials

The ldif I used to add the Admin acount is identical ass that of the
Manager :

root.ldif 

dn: uid=root,ou=Idmap,dc=thales,dc=be
uid: root
cn: Admin
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$lB0twC9d$i542IIFLEH11VLUzdEUr91
shadowLastChange: 13041
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 0
gidNumber: 0
homeDirectory: /root
gecos: root

Any ideas off what I'm doing wrong?

Thanks,

On Tue, 2005-09-27 at 15:02 +0200, paul kölle wrote: 

> Kristof Bruyninckx wrote:
> > # Use the OpenLDAP password change
> > # extended operation to update the password.
> > pam_password md5
> If you want it to do what the comment suggest this should read:
> pam_password exop
> 
> 
> > dn: cn=Manager,dc=thales,dc=be
> > objectClass: organizationalRole
> > cn: Manager
> > description: Directory Manager
> I think that may be your problem. The DN is the same as your rootdn in
> slapd.conf but does not have a userPassword attribute. It might "shadow"
> your rootdn making binds with that DN fail (see below). You don't have
> to add the "rootdn" from slapd.conf to your directory but it is
> generally discouraged to use it in daily operations as ACLs do not apply
> to "rootdn".
> 
> 
> > Sep 27 13:31:47 linux14 slapd: => access_allowed: auth access to
> > "cn=Manager,dc=thales,dc=be" "userPassword" requested
> > Sep 27 13:31:47 linux14 slapd: => access_allowed: backend default auth
> > access granted to "(anonymous)"
> > Sep 27 13:31:47 linux14 slapd: send_ldap_result: err=49 matched=""
> err=49 means "invalid credentials" most likely due to the missing
> "userPassword" attribute of cn=manager,dc=thales,dc=be.
> 
> 
> Try removing cn=Manager,dc=thales,dc=be from your ldif and see if you
> can bind with rootdn and rootpw from your slapd.conf. If that works
> create another entry in your DIT with a userPassword attribute, give it
> appropriate permissions in slapd.conf and use that for your "ldap admin
> dn" in smb.conf
> 
> hth
>  Paul


-- 
Kristof.Bruyninckx

We are Microsoft.  What you are experiencing is not a problem; it is an
undocumented feature.