Directory Programming .NET

Sorry if this is outside what the forum is intended for (SAM rather than AD/ADAM/LDAP) but I am really hoping someone has some insight into a very peculiar problem.

I have an ASP.NET 3.5 application that is designed to create and configure Windows users on the local web server and also on a remote server. The purpose of these accounts is to give website users an FTP account. I am using the System.DirectoryServices.AccountManagement namespace. There is no Active Directory involved - we are just talking about creating local Windows users.

The ASP.NET process is running under the regular (non-admin) NETWORK SERVICE acccount. An administrator account is specified in the PrincipalContext through which all functions are run.

Something very wierd is going on .... I have now tested several different user & group management functions, and some work and others don't. Whether they work or not is affected by 2 things: (i) whether the SAM store is on the same server as the app or on a remote server, and (ii) whether the machine/host name or machine IP address is specified in the PrincipalContext.

Here are my findings. If anyone can explain this and suggest a solution I would be verrrry grateful.

FYI, all functions were run through a PrincipalContext set up as follows:

static PrincipalContext _PrincipalContext;
_PrincipalContext = new PrincipalContext(ContextType.Machine, _WindowsServerName, null, "LocalAdminUsername", "LocalAdminPassword");

 

	SAM store on the same server as your ASP.NET app		SAM store on a remote server from your ASP.NET app
Function	machine name in the PrincipalContext	machine IP address in the PrincipalContext	host name in the PrincipalContext (name set up in Hosts file)	machine IP address in the PrincipalContext
Creating a user	"General access denied” * error	OK	OK	OK
Checking if a user exists	OK	OK	OK	OK
Checking if a group exists	OK	OK	OK	OK
Checking if a user is in a group	OK	always returns false	OK	always returns false
Adding a user to a group	OK	OK	OK	OK
Removing a user from a group	"General access denied” ** error	does not error, but no change is made	OK	does not error, but no change is made
Deleting a user	"General access denied” *** error	OK	OK	OK
Disabling & re-enabling a user	"General access denied” **** error	OK	OK	OK
Setting user password	"Exception thrown” ***** error	OK	OK	OK

 

* General access denied error ---> System.UnauthorizedAccessException: General access denied error at System.DirectoryServices.Interop.UnsafeNativeMethods.IAds.SetInfo() at System.DirectoryServices.DirectoryEntry.CommitChanges() at System.DirectoryServices.AccountManagement.SDSUtils.ApplyChangesToDirectory(Principal p, StoreCtx storeCtx, GroupMembershipUpdater updateGroupMembership, NetCred credentials, AuthenticationTypes authTypes) at System.DirectoryServices.AccountManagement.SDSUtils.InsertPrincipal(Principal p, StoreCtx storeCtx, GroupMembershipUpdater updateGroupMembership, NetCred credentials, AuthenticationTypes authTypes, Boolean needToSetPassword) at System.DirectoryServices.AccountManagement.SAMStoreCtx.Insert(Principal p) at System.DirectoryServices.AccountManagement.Principal.Save()

** General access denied error ---> at System.DirectoryServices.AccountManagement.UnsafeNativeMethods.IADsGroup.Remove(String bstrItemToBeRemoved) at System.DirectoryServices.AccountManagement.SAMStoreCtx.UpdateGroupMembership(Principal group, DirectoryEntry de, NetCred credentials, AuthenticationTypes authTypes) at System.DirectoryServices.AccountManagement.SDSUtils.ApplyChangesToDirectory(Principal p, St

*** General access denied error ---> at System.DirectoryServices.Interop.UnsafeNativeMethods.IAdsContainer.Delete(String className, String relativeName) at System.DirectoryServices.DirectoryEntries.Remove(DirectoryEntry entry) at System.DirectoryServices.AccountManagement.SDSUtils.DeleteDirectoryEntry(DirectoryEntry deToDelete) at System.DirectoryServices.AccountManagement.SAMStoreCtx.Delete(Principal p)

**** General access denied error ---> at System.DirectoryServices.Interop.UnsafeNativeMethods.IAds.SetInfo() at System.DirectoryServices.DirectoryEntry.CommitChanges() at System.DirectoryServices.AccountManagement.SDSUtils.ApplyChangesToDirectory(Principal p, StoreCtx storeCtx, GroupMembershipUpdater updateGroupMembership, NetCred credentials, AuthenticationTypes authTypes)

***** Exception has been thrown by the target of an invocation. ---> at System.DirectoryServices.DirectoryEntry.Invoke(String methodName, Object[] args) at System.DirectoryServices.AccountManagement.SDSUtils.SetPassword(DirectoryEntry de, String newPassword) at System.DirectoryServices.AccountManagement.SAMStoreCtx.SetPassword(AuthenticablePrincipal p, String newPassword)

That's a really thorough analysis.  Thanks for posting!  I'm guessing some of the problems between IP address and host name may be related to Kerberos authentication being used vs. NTLM, but it is not clear to me why that would make a difference.

I think the best thing for me to do would be to point out this thread to some people at Microsoft and see if I can get their attention regarding it.

One thing you might consider trying would be instead of specifying credentials in the PrincipalContext constructor, you write some impersonation code to impersonate the admin user (MSDN has a nice sample associated with the WindowsImpersonationContext class) and then use default credentials for the PrincipalContext instead.  It may be the case that some of the underlying calls don't work well with supplied credentials or there is some inconsistency in how they are implemented that manifests this way.

The other thing you might consider doing as a test (probably not as a solution though!) would be to configure your app pool to run as the admin user and eliminate the impersonation entirely.

I'll see what I can do about getting some attention from MS about this.

Thanks for quick response. I was getting so confused with functions sometimes working and sometimes not I tested every combination of conditions to get my head straight!

Impersonation (set in the web.config) and running the App Pool as an administrator do work, but I am trying to avoid the whole site running with admin permissions for security. However the WindowsImpersonationContext class looks promising - looks like you can impersonate another user for a limited peroid of time then revert back to default. Thanks for the hint!

Thanks for offering to contact MS also. It would be great if I could get my code working without a drastic rewrite.

Any news?

No, not yet.  The mailing list I typically use for contacting the product team currently has me locked out and the guys who run the list have not been responding to my requests to get it fixed.  I'm not sure what's going on but I'm kind of stuck right now.

Did you try out the impersonation approach to see if it provides more consistent results?

I did try out the impersonation approach, and I am happy to say it solved all my problems! Thanks very much for the pointer.

I had one thought about a possible source of problems I reported ...

In my code, I have 2 PrincipalContext objects alive at the same time, pointing to 2 different servers. If, under the hood, the PrincipalContext sets up impersonation (in the same way that the WindowsImpersonationContext class does) I wonder if attempting to set it up twice is confusing things (because the thread can only impersonate one user at a time)?

Now I have rewritten my app to use the WindowsImpersonationContext class I don't have space to test this idea, so if you do get MS to look at my report that would still be appreciated.

Glad you found a good solution.  I'll provide those details when I get this in front of someone.

I'm unfortunately still locked out of my feedback channel and have not gotten a response from the people I need to talk to that can get it reestablished so I have nothing good to report yet.  Sorry about that. :(

joe:

One thing you might consider trying would be instead of specifying credentials in the PrincipalContext constructor, you write some impersonation code to impersonate the admin user (MSDN has a nice sample associated with the WindowsImpersonationContext class) and then use default credentials for the PrincipalContext instead.  It may be the case that some of the underlying calls don't work well with supplied credentials or there is some inconsistency in how they are implemented that manifests this way.

Hi,

I had the same error as Ineville, but the default msdn WindowsImpersonationContext class did not worked for me.

I want to change the password of an admin account on a remote computer from a server (using a wcf web service). But the account does not exists on the server (it's a local admin account, that exists only on the remote computer), so the native LogonUser method returned false.

I found another version of this class, allowing to use other LogonType and LogonProvider. And it works with LogonType = LOGON32_LOGON_NEW_CREDENTIALS (= 9) and LogonProvider = LOGON32_PROVIDER_WINNT50 (= 3) !

More on : http://platinumdogs.wordpress.com/2008/10/30/net-c-impersonation-with-network-credentials/

The "new credentials" flag gives your code the behavior of using the current security context when executing locally, but when you code attempts an RPC call to the remote system, it will instead use the new credentials.  As you discovered, this is very helpful in cases where the account you wish to use only exists on the remote system such as in the case of a local machine account on a different box.

Tks for this explanation :)

I just saw that there is a nice Impersonation Component posted by Dunnry on this site !
Download it on : http://directoryprogramming.net/files/3/freetools/entry636.aspx