I've managed to get Samba to store its passdb in an LDAP (openldap 2.0.18) backend (using 2.2 cvs from about a week ago) and all is working well except in a multi-ldap-server configuration. When I am communicating with the master ldap server, I am able to add/change/delete entries. When communicating with a slave ldap server, I get a referral to the master ldap server to make the change. When samba contacts the master ldap server, it doesn't bind with the appropriate dn to authenticate and make the change. I am using simple authentication (ie not SASL) and am not currently using SSL. Here's a command I tried: marshallj@10.10.10.11:~$ sudo smbpasswd fred New SMB password: Retype new SMB password: failed to modify user with uid = fred with: Insufficient access Failed to modify entry for user fred. Failed to modify password entry for user fred Here's a snippet of the logs: Jan 23 13:07:32 slaveldap slapd[15472]: daemon: conn=11 fd=14 connection from IP=10.10.10.11:4005 (IP=0.0.0.0:34049) accepted. Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=0 BIND dn="UID=MARSHALLJ,OU=PEOPLE,DC=USSAUS" method=128 Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=0 RESULT tag=97 err=0 textJan 23 13:07:32 slaveldap slapd[15472]: deferring operation Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=1 SRCH base="ou=samba,dc=ussaus" scope=2 filter="(&(uid=fred)(objectClass=sambaAccount))" Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=1 SEARCH RESULT tag=101 err=0 textJan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=2 MOD dn="uid=fred,ou=samba,dc=ussaus" Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=2 RESULT tag=103 err=9 text=Referral: ldap://masterldap.ussbris Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=3 UNBIND Jan 23 13:07:32 slaveldap slapd[15480]: conn=-1 fd=14 closed Jan 23 13:07:32 masterldap slapd[5268]: daemon: conn=62 fd=15 connection from IP=10.10.10.11:4006 (IP=0.0.0.0:34049) accepted. Jan 23 13:07:32 masterldap slapd[5274]: conn=62 op=0 BIND dn="" method=128 Jan 23 13:07:32 masterldap slapd[5274]: conn=62 op=0 RESULT tag=97 err=0 textJan 23 13:07:32 masterldap slapd[5287]: conn=62 op=1 MOD dn="uid=fred,ou=samba,dc=ussaus" Jan 23 13:07:32 masterldap slapd[5287]: conn=62 op=1 RESULT tag=103 err=50 textJan 23 13:07:32 masterldap slapd[5286]: conn=62 op=2 UNBIND Jan 23 13:07:32 masterldap slapd[5286]: conn=-1 fd=15 closed Jan 23 13:07:32 masterldap slapd[5268]: conn=-1 fd=10 closed Notice that when 10.10.10.11 connects to the master ldap server, it sends an empty dn in the BIND operation. I assume this is a bug in the software (be it samba or a library it uses) - is there a work-around for this? Thanks for any assistance, Josh Marshall
Have you enter the password of the bind admin dn with "smbpasswd" ? Pascal Schelcher. ----- Original Message ----- From: <MarshallJ@switch.aust.com> To: <samba@samba.org> Sent: Wednesday, January 23, 2002 4:13 AM Subject: Samba and referrals in LDAP> I've managed to get Samba to store its passdb in an LDAP (openldap 2.0.18) > backend (using 2.2 cvs from about a week ago) and all is working well > except in a multi-ldap-server configuration. > > When I am communicating with the master ldap server, I am able to > add/change/delete entries. When communicating with a slave ldap server, I > get a referral to the master ldap server to make the change. When samba > contacts the master ldap server, it doesn't bind with the appropriate dn > to authenticate and make the change. > > I am using simple authentication (ie not SASL) and am not currently using > SSL. > > Here's a command I tried: > > marshallj@10.10.10.11:~$ sudo smbpasswd fred > New SMB password: > Retype new SMB password: > failed to modify user with uid = fred with: Insufficient access > > Failed to modify entry for user fred. > Failed to modify password entry for user fred > > Here's a snippet of the logs: > > Jan 23 13:07:32 slaveldap slapd[15472]: daemon: conn=11 fd=14 connection > from IP=10.10.10.11:4005 (IP=0.0.0.0:34049) accepted. > Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=0 BIND > dn="UID=MARSHALLJ,OU=PEOPLE,DC=USSAUS" method=128 > Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=0 RESULT tag=97 err=0 > text> Jan 23 13:07:32 slaveldap slapd[15472]: deferring operation > Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=1 SRCH > base="ou=samba,dc=ussaus" scope=2 > filter="(&(uid=fred)(objectClass=sambaAccount))" > Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=1 SEARCH RESULT tag=101 > err=0 text> Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=2 MOD > dn="uid=fred,ou=samba,dc=ussaus" > Jan 23 13:07:32 slaveldap slapd[15481]: conn=11 op=2 RESULT tag=103 err=9 > text=Referral: ldap://masterldap.ussbris > Jan 23 13:07:32 slaveldap slapd[15480]: conn=11 op=3 UNBIND > Jan 23 13:07:32 slaveldap slapd[15480]: conn=-1 fd=14 closed > > > Jan 23 13:07:32 masterldap slapd[5268]: daemon: conn=62 fd=15 connection > from IP=10.10.10.11:4006 (IP=0.0.0.0:34049) accepted. > Jan 23 13:07:32 masterldap slapd[5274]: conn=62 op=0 BIND dn="" method=128 > Jan 23 13:07:32 masterldap slapd[5274]: conn=62 op=0 RESULT tag=97 err=0 > text> Jan 23 13:07:32 masterldap slapd[5287]: conn=62 op=1 MOD > dn="uid=fred,ou=samba,dc=ussaus" > Jan 23 13:07:32 masterldap slapd[5287]: conn=62 op=1 RESULT tag=103 err=50 > text> Jan 23 13:07:32 masterldap slapd[5286]: conn=62 op=2 UNBIND > Jan 23 13:07:32 masterldap slapd[5286]: conn=-1 fd=15 closed > Jan 23 13:07:32 masterldap slapd[5268]: conn=-1 fd=10 closed > > > Notice that when 10.10.10.11 connects to the master ldap server, it sends > an empty dn in the BIND operation. > > I assume this is a bug in the software (be it samba or a library it uses) > - is there a work-around for this? > > Thanks for any assistance, > > Josh Marshall > > > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba >
On Wed, 23 Jan 2002 MarshallJ@switch.aust.com wrote:> I've managed to get Samba to store its passdb in an LDAP (openldap 2.0.18) > backend (using 2.2 cvs from about a week ago) and all is working well > except in a multi-ldap-server configuration. > > When I am communicating with the master ldap server, I am able to > add/change/delete entries. When communicating with a slave ldap server, I > get a referral to the master ldap server to make the change. When samba > contacts the master ldap server, it doesn't bind with the appropriate dn > to authenticate and make the change. > > I am using simple authentication (ie not SASL) and am not currently using > SSL.This is probably a bug. I've got a patch lying around for this (submitted by someone on samba-technical but I've not had time to review ti and check it in). You can check the samba-technical ml archives for the patch and try it yourself (although it may not go in in its current form). chau, jerry --------------------------------------------------------------------- Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org -- http://www.plainjoe.org "Sam's Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Hi Jerry, I managed to work out what was happening before you posted this. When communicating with a slave ldap, and an add/change/delete request is sent to the server, the ldap server replies with an error code which refers the client software (in this case samba) to the master ldap server. It is up to the client software then to connect to the master ldap server and resubmit the request. The problem with the simple binding is that referrals are generally followed anonymously. This is fine for most lookups but for modifying the data there is a security issue allowing anonymous modifications. In the configuration that samba uses, the authentication on both the master and slave server is the same. So what needs to be added to the current implementation is a way to get the referral to use the same authentication to the master server. This is easily done by using the rebindproc() function from the openldap libraries. What this does is if a referral takes place, it calls a particular function who's job it is to authenticate to the new ldap server. Once that's done the request is submitted to the master ldap and the change is allowed. I put together the required changes to pdb_ldap.c and have tested it in both ssl and non-ssl modes, and it works wonderfully. Please can you consider adding the following patch to the cvs tree (patch is against pdb_ldap.c cvs version 1.1.2.21) I now have a Samba PDC with an SSL-secured LDAP backend that works in a distributed master-slave configuration (the slaves are remote offices with a local Samba PDC to handle logon requests for the LAN). Thanks go to the Samba team to make all of this possible. Regards, Joshua Marshall Systems Support Engineer Union Switch & Signal Pty Ltd Ph: (07) 3868 9371 Fx: (07) 3268 2219 -------------- next part -------------- A non-text attachment was scrubbed... Name: pdb_ldap.patch Type: application/octet-stream Size: 1647 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/20020123/0ede5637/pdb_ldap.obj