----- Original Message -----
From: "Duncan Brannen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[email protected]>
Sent: Tuesday, May 30, 2006 12:23 PM
Subject: Re: [Samba] Domain Logins across VPN
[EMAIL PROTECTED] wrote:
----- Original Message -----
From: "Duncan Brannen" <[EMAIL PROTECTED]>
Cc: <[email protected]>
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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/listinfo/samba
