[Samba] Domain Logins across VPN

Tue May 30 20:26:15 GMT 2006

----- Original Message ----- 
From: "Duncan Brannen" <dbb at st-andrews.ac.uk>
To: <rob at desynched.net>
Cc: <samba at lists.samba.org>
Sent: Tuesday, May 30, 2006 12:23 PM
Subject: Re: [Samba] Domain Logins across VPN

> rob at desynched.net wrote:
>> ----- Original Message -----
>> From: "Duncan Brannen" <dbb at st-andrews.ac.uk>
>> Cc: <samba at lists.samba.org>
>> Sent: Friday, May 26, 2006 4:12 AM
>> Subject: Re: [Samba] Domain Logins across VPN
>>
>>
>>
>>>> This configuration works. If I change passdb to 127.0.0.1 instead of
>>>> the Master LDAP's IP, this pops up in samba.smbd:
>>>>
>>>> [2006/05/24 14:53:30, 1] lib/smbldap_util.c:add_new_domain_info(198)
>>>>  failed to add domain dn=
>>>> sambaDomainName=ATWORK,dc=atworkpersonnel,dc=com with: Server is
>>>> unwilling to perform
>>>>        shadow context; no update referral
>>>> [2006/05/24 14:53:30, 0]
>>>> lib/smbldap_util.c:smbldap_search_domain_info(258)
>>>>  Adding domain info for ATWORK failed with NT_STATUS_UNSUCCESSFUL
>>>>
>>>>
>>>> That's the only error I see popping up. Ideas?
>>>>
>>> Has the entry dn= sambaDomainName=ATWORK,dc=atworkpersonnel,dc=com
>>> replicated across to your slave
>>> ldap server successfully?
>>>
>>> Check your ldap logs on the slave, I think samba does a lookup for the
>>> domain and adds it if it doesn't exist, otherwise
>>> is the updateref set in your slaves slapd.conf file?  If the slave ldap
>>> server is telling samba it doesn't accept changes but
>>> not telling it where to send changes ( no update referral) you might get
>>> this problem.
>>>
>>> Hope this helps
>>>
>>>       Duncan
>>>
>>
>> Hi Duncan,
>> I'm not using slurpd for replication; I'm using syncrepl. The database
>> exists and is updated fine (if I add a user on the master, it exists on 
>> the
>> slave, etc).
>>
>> I'm using the smbldap tools for samba, and on the slave machines, they
>> generate an error any time I try to use them (unless I point them at the
>> Master LDAP).
>>
>> for example, if I try this:
>> smbldap-useradd -a testuser
>>
>> it returns:
>> Error: shadow context; no update referral at
>> /usr/local/sbin//smbldap_tools.pm line 1005.
>>
>>
>> I believe this has something to do with the issue.
>>
>> --
>> Rob
>>
>
> Hi Rob,
>         The replication method shouldn't matter.  updateref is used for 
> both slurpd and syncrepl and tells the slave
> where to send clients who try to make changes.
>
> eg
> Samba -> ldap slave "Add/Update this entry"
> ldap slave -> samba "I don't accept changes, please write to the master at 
> <updateref> "
>
> If you don't have updateref set, the slave will refuse the change but not 
> tell the client where to make the change.
>
> If you do have updateref set and it still doesn't work,
>
> I'd try to add an entry using the (I assume openldap) client tools to the 
> slave, check the slave logs, turning up logging if necessary
> and the master logs.  You should see the client connect to the slave, get 
> an error and an updateref, then the change
> should show up in the logs of the master.
> If the slave returns the updateref but the client does not then contact 
> the master, the client doesn't understand update references
> and you'll need to update your clients or make changes to the master 
> directly.
>
> If it works using the openldap tools, try it again with the samba ldap 
> tools, you should see the same thing,
> client connects to slave, slave provides update ref, client connects to 
> and updates master.
>
> I'm fairly sure my BDC's didn't try to write to the ldap servers after the 
> PDC had written the domain info in.
> (Though I wouldn't swear I checked)
> Can the samba user can pull out the complete domain info using ldapsearch?
>
> Any joy?
>
>   Duncan

Well, I added the updateref directive to the slave's slapd.conf file - now 
the error msg has changed to:

Error: Referral received at /usr/local/sbin//smbldap_tools.pm line 1005.

ldapsearch works fine - I'm assuming that's because the database is sync'd 
and it's searching locally.

/var/log/debug shows this upon an attempt to run smbldap-useradd:

May 30 16:19:28 bgserver slapd[9602]: conn=1 fd=13 ACCEPT from 
IP=127.0.0.1:54940 (IP=0.0.0.0:389)
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=0 EXT 
oid=1.3.6.1.4.1.1466.20037
May 30 16:19:28 bgserver slapd[9602]: do_extended: unsupported operation 
"1.3.6.1.4.1.1466.20037"
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=0 RESULT tag=120 err=2 
text=unsupported extended operation
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=1 BIND 
dn="cn=Manager,dc=atworkpersonnel,dc=com" method=128
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=1 BIND 
dn="cn=Manager,dc=atworkpersonnel,dc=com" mech=SIMPLE ssf=0
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=1 RESULT tag=97 err=0 text=
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=2 SRCH 
base="dc=atworkpersonnel,dc=com" scope=2 deref=2 
filter="(&(objectClass=posixAccount)(uid=testuser))"
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=2 SEARCH RESULT tag=101 
err=0 nentries=0 text=
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=3 SRCH 
base="sambaDomainName=ATWORK,dc=atworkpersonnel,dc=com" scope=0 deref=2 
filter="(objectClass=sambaUnixIdPool)"
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=3 SEARCH RESULT tag=101 
err=0 nentries=1 text=
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=4 MOD 
dn="sambaDomainName=ATWORK,dc=atworkpersonnel,dc=com"
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=4 MOD attr=uidNumber
May 30 16:19:28 bgserver slapd[9602]: conn=1 op=4 RESULT tag=103 err=10 
text=
May 30 16:19:28 bgserver slapd[9602]: conn=1 fd=13 closed (connection lost)

The master's /var/log/debug shows nothing.

--
Rob 