Exception Stack:
System.UnauthorizedAccessException: General access denied error at
System.DirectoryServices.AccountManagement.ADStore Ctx.Insert(Principal p) at
System.DirectoryServices.AccountManagement.Princip al.Save() at ...

My code runs fine before, but it suddenly not worked for create AD users
since yesterday, however, it still worked for create local machine users,:

Account a = new Account(account);
if (!principalContexts.ContainsKey(a.Domain))
{
return ErrorMsg.Invalid_Account;
}
PrincipalContextStore pcs = principalContexts[a.Domain];
PrincipalContext ctx = pcs.Context;
if (ctx == null)
{
return ErrorMsg.Invalid_Account;
}
UserPrincipal p = UserPrincipal.FindByIdentity(ctx,
a.UserName);
if (p != null)
{
return ErrorMsg.Duplicate_Account;
}

Console.WriteLine(ctx.ValidateCredentials(pcs.Oper atorAccount.UserName,
pcs.OperatorPassword));
p = new UserPrincipal(ctx, a.UserName, password, true);

Console.WriteLine(string.Format("Options={0}\r\nCo nnectedServer={1}\r\nName={2}\r\nUserName={3}\r\n" ,ctx.Options.ToString(),ctx.ConnectedServer,ctx.Na me,ctx.UserName));
p.Save();
return ErrorMsg.None;

The PrincipalContext user credential is right, some AD read operations are
working fine (such as PrincipalContext.ValidateCredentials()), and the user
can create the AD users in Windows computer management normally.

Please kindly advise.

Thanks!

This error is returned by the server when the write operation is attempted,
so the problem has to be with the credentials.

One thing you can do is use the same credentials with SDS to bind to the
container you are writing to and using RefreshCache to get the
allowedChildClassesEffective attribute. It will return an array of strings
containing the names of the objectClass values that the current user has
rights to create in the specific container.

Hi, Joe,

I wrote the following code, it ran ok but return nothing, I am not sure the
code is correct:

ActiveDirectorySchema adSchema =
ActiveDirectorySchema.GetSchema(new
DirectoryContext(DirectoryContextType.Forest, pcs.LdapServer,
pcs.OperatorAccount.UserName, pcs.OperatorPassword));
ReadOnlyActiveDirectorySchemaClassCollection classes =
adSchema.FindAllClasses(SchemaClassType.Structural );
foreach (ActiveDirectorySchemaClass schemaClass in classes)
{
// Get the entry to retreive all properties/attributes
DirectoryEntry entry = schemaClass.GetDirectoryEntry();
entry.RefreshCache(new string[] {
"allowedChildClassesEffective" });
PropertyValueCollection properties =
entry.Properties["allowedChildClassesEffective"];
for (int i = 0; i < properties.Count; i++)
Console.WriteLine(properties[i]);
}

I tried to use Sysinternals tool ADExplorer to search the objects by
(allowedChildClassesEffective=*) filter, it pops up the "inappropriate
matching" message and do nothing.

Thanks,
dotAge

"Joe Kaplan" wrote:
[..]

You need to create a DirectoryEntry that references the container object
(OU, etc.) that you were trying to use to create the user objects under.
Read the allowedChildClassesEffective attribute from it. Reading it from a
schema object will give you totally different results and would be
misleading since you are not trying to create users in the schema container.
You can't use this attribute in a filter since it is constructed. I also
recommend using Microsoft's LDP tool for testing your queries.

Hi, Joe,

I am new to AD programming, can you please supply me the sample code and LDP
command usage hint about these?

Thank you very much!
dotAge

"Joe Kaplan" wrote:
[..]

Most of the code you have is fine. The key is that when you call
RefreshCache on the DirectoryEntry object, the DirectoryEntry must point to
the container where you were trying to create the users. You need to know
the distinguished name of that container. It is probably in the constructor
you used for creating your PrincipalContext for SDS.AM if you were trying to
create users in a specific container. Normally, you would not create users
in the partition root anyway.

Now, I am sure my code has no problem. When I connect to a test OU in our
INTRA domain, it returns 128 properties for allowedChildClassesEffective
attribute, and the new account could be created successfully.
But when I connect to another domain DMZ, it returns nothing for
allowedChildClassesEffective attribute, and the user creating failed by
"Access denied" exception. The DMZ domain has not any OU, all users are
placed in the root of container, for example, all user's distinguishedName
are "CN=username,CN=Users,DC=DMZ,DC=corp", so I think the context container
should be "DC=DMZ,DC=corp", in fact, it is connected correctly, because I
found the ConnectedServer is dc1.DMZ.corp, one DC of the DMZ domain. tried
forcing it connect to dc2.DMZ.corp, failed with no difference.
I am really confused, why I can create users in MMC, but can't create them
in code? Both executed by the same DMZADMIN account!
BTW, there is one difference is that our INTRA domain controllers are WIN
2003, but DMZ are WIN 2000 sp4. I don't know does it helps.

Thank you!
dotAge

"Joe Kaplan" wrote:
[..]

You need to set up your PrincipalContext to point to the CN=Users container
if you want to create users there. If you create the PrincipalContext
pointed to the partition root (or use the default), your code will try to
create users in the root which is probably not what you want.

Also, ensure that the account you use to create the context has permissions
to create user objects there. It looks like it does not currently.

Now, we created a new OU under the root container, administrator granted to
the DMZADMIN account FullControl permission for the OU , then we change the
container configuration from root to OU, my code worked without any
modification.
Though why before permission setting causes the difference between MMC and
..Net code, I do have not more time to study it. The most important is that
our application is working and secure.

Thank you for your helps!
dotAge

"Joe Kaplan" wrote:
[..]