user unable to create a user in a replicated from w2k3 server

[Stefan (metze) Metzmacher]

Am 06.07.2010 06:28, schrieb Matthieu Patou:
>  On 06/07/2010 02:35, Andrew Bartlett wrote:
>> On Tue, 2010-07-06 at 01:32 +0400, Matthieu Patou wrote:
>>> Hello tridge, Andrew, Metze,
>>>
>>> I was with plaerzen on IRC, he managed to update his w2k server to w2k3
>>> and then made s4 vampire it.
>>>
>>> He is now unable to create user on the S4 server.
>>>
>>> A level 10 log is here:
>>>
>>> http://pastebin.com/Werib9g9
>>>
>>> I made some analysis my conclusion is that he has this pb: msg:
>>> ../dsdb/samdb/ldb_modules/ridalloc.c:450: No RID Set DN - Remote RID Set
>>> allocation needs refresh.
>>>
>>> Then we created a sample ldif file to create more easily the user from
>>> command line :
>>>
>>> ldbmodify -H ldap://s4ldap /tmp/t.ldif -k 1
>>>
>>> We get:
>>> ERR: (Unwilling to perform) "LDAP error 53 LDAP_UNWILLING_TO_PERFORM -
>>> <00002035: Unwilling to perform -
>>> ../dsdb/samdb/ldb_modules/ridalloc.c:450:  No RID Set DN - Remote RID
>>> Set allocation needs refresh>  <>" on DN CN=testsix,CN=Users,DC=....
>> Yeah, something has broken about our remote RID set allocation.  A good
>> test for this would be to run the RPC-SAMR-LARGE-DC test against our
>> vampire_dc in 'make test'.
>>
>>> The same command against the w2k3 dc works ...
>>>
>>> I put more trace and came to the conclusion that this line is failing
>>> "if (ldb_dn_compare(samdb_ntds_settings_dn(ldb), fsmo_role_dn) != 0) {"
>>>
>>> Indeed we have this:
>>>
>>> ntds: CN=NTDS
>>> Settings,CN=DEV-TEADC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=winteal,DC=tundraeng,DC=com
>>>
>>>
>>>
>>> fsmo: CN=NTDS Settings,CN=DEV-TEDC3,CN=Servers,CN=Default-First-
>>> Site-Name,CN=Sites,CN=Configuration,DC=winteal,DC=tundraeng,DC=com
>>>
>>>
>>> So clearly the DN are different ....  to my mind the test is not good as
>>> globably the samdb_ntds_settings_dn is a search for dsServiceName on the
>>> rootdse and it seems that for each server it returns only the ntds of
>>> this server, so the test is likely to work only on the server which is
>>> rid master.
>> Correct.  We can only do this locally if we are the RID Master, if not,
>> we need to ask the RID Master to allocate us some RIDs.
> Well given this code:
>         if (ldb_dn_compare(samdb_ntds_settings_dn(ldb), fsmo_role_dn) !=
> 0) {
>                 ridalloc_poke_rid_manager(module);
>                 ldb_asprintf_errstring(ldb, "Remote RID Set allocation
> needs refresh");
>                 talloc_free(tmp_ctx);
>                 return LDB_ERR_UNWILLING_TO_PERFORM;
>         }
> 
> I understand that this happens all the time on any DC that is not a RID
> master, is it the wanted behavior ?
> If so I suppose that when we poke the RID manager, or more precisely
> when we receive the answer, that we should create a RID Set in return.

I think this is a timing issue, we should already poke the rid master
if we have use half of the existing pool.

You should try to create network trace together a log level 100 log file.

and run the following loop:

for i in `seq 1000 1999`; do
	ldbsearch -H ldap://somehost.example.com -UAdministrator%pw \
		'(objectClass=rIDSet)' rIDAllocationPool rIDNextRID
rIDPreviousAllocationPool | grep -i rid
	echo "dn: CN=testuser$i,CN=Users,DC=EXAMPLE,DC=COM" > /tmp/$$.loop
	echo "objectClass: user" >> /tmp/$$.loop
	echo "sAMAccountName: testuser$i" >> /tmp/$$.loop
	ldbadd -H ldap://somehost.example.com -UAdministrator%pw --verbose <
/tmp/$$.loop || break
	sleeptime=1
	echo "Sleep $sleeptime..."
	sleep $sleeptime
done

And change sleeptime also to 0 and compare the output.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20100706/9a036ce3/attachment.pgp>