Partial or deferred creation of accounts after RID allocation failure?

[Mike Snowden]

I've been having an odd problem recently. An application that creates users
in AD for application authentication (first under the standard cn=users
entry on the WinNT provider, then moves them into a parallel folder via a
MoveHere on the LDAP provider) is failing intermittently - usually by the
rename apparently failing. We've failed to reproduce this, but may now have
seen this ourselves.

I was thrash-testing the account creation code, when I got a RID allocation
failure (see below for the event details). This was probably because the
connection between the RID master (this machine) and the Domain master was
down, due to some extra network restrictions this week...

I then got an immediate creation failure for all further creations.

Once the event to say that a new RID block request was pending had appeared
in the log, things got a little more complicated. The next creation request
appeared to succeed, but when the MoveHere was tried, it failed. Checking
using the AD "Users and Domains" MMC console failed to see the "new"
account, but a direct open using the WinNT provider succeeded. We still
hadn't reconnected to the domain controller, so I haven't yet been able to
check whether this account will become a real one.

I am assuming that what I have run into is some partial buffering, that is
just intended to allow account operations to proceed while a new RID is
fetched. However it only seems to hide the failure inside the WinNT
provider. When you do anything outside this, it fails immediately. We've
used the LDAP provider, due to the warnings that MoveHere doesn't do domain
moves, just renames, for the WinNT provider - and all the examples use LDAP.

1) Is this the expected behaviour?
2) Will the account appear when the RID block is returned?
3) The new account folder is a parallel branch to the Users one - the next
level up is common. Should this work with the WinNT provider and under the
"buffered" creation, so we can avoid a failure - or should we pick up the
MoveHere failure as a creation failure, and clean up the account that is
lying there, hidden? Or is there a better way to create a user entry,
preferably directly in the correct folder?

Thanks in advance,
Mike

====================================================
If you want to reply directly, please remove the NOSPAM. from my address
====================================================

OS: Win2000 SP3 or SP4

Creation code:

Dim DomainController As IADsContainer
Dim NewUser As IADsUser
Set DomainController = GetObject(szADsPath)
Set NewUser = DomainController.Create("user", szAccountName)
...
NewUser.SetPassword ("********")
NewUser.SetInfo


====================================================



Event Type: Error
Event Source: SAM
Event Category: None
Event ID: 16645
Date: 15/08/2003
Time: 18:36:12
User: N/A
Computer: *********
Description:
The maximum account identifier allocated to this domain controller has been
assigned. The domain controller has failed to obtain a new identifier pool.
A possible reason for this is that the domain controller has been unable to
contact the master domain controller. Account creation on this controller
will fail until a new pool has been allocated. There may be network or
connectivity problems in the domain, or the master domain controller may be
offline or missing from the domain. Verify that the master domain controller
is running and connected to the domain.

Data:
0000: a8 02 00 c0 ¨..À

 

[Tim Springston \(MSFT\)]

Hi Mike-

It sounds like the domain controller(s) at your location have exhausted the
allocated RID pool. This would be expected behavior if that is the case. A
relative identifier is needed for operations like creating new objects in
the directory. If the relative identifier pool is empty, new object
creation will fail.

To find out for sure, you can run DCDIAG /V (from the Support Tools) and
look at the RIDManager test. Here's an exmaple of a good one:

Starting test: RidManager
* Available RID Pool for the Domain is 29907 to 1073741823
* testdc3.testdomain.com is the RID Master
* DsBind with RID Master was successful
* rIDAllocationPool is 28907 to 29406
* rIDPreviousAllocationPool is 28907 to 29406
* rIDNextRID: 28930
......................... TESTDC1 passed test RidManager

Getting the failing domain controller(s) back into contact with the RID
Master FSMO role owner should resolve this. If it does not, please post a
reply and let us know.

 

[Mike Snowden]

Tim,
Thank you for the quick reply - I'll run the tests tomorrow.

I know the request has got as far as the RID controller, which is running on
a Domain controller - aka the box the request was targeted at, so it's the
"master domain controller" communication that has failed.

What surprised me was the creation calls apparently succeeding, but the
account not being visible through either LDAP or the User & Domain MMC.
This matched exactly what our users were seeing from site - either the
MoveHere failing with a "no such object" error or "account already exists"
on a retry after the previous failure - but not visible by MMC when they
checked,. Of course, their system event log was full, so there weren't any
events logged, but this seems a plausible scenario - unless there are any
other conditions with similar symptoms you can think of?

I'm tempted to rewrite the code to back off the creation if this condition
occurs, so the users at least don't get confused.


Mike Snowden