none
Requirements for System.DirectoryServices.AccountManagement methods RRS feed

  • Question

  • I am using .NET methods from the namespace System.DirectoryServices.AccountManagement to find users, find groups, and determine group membership in active directory. It works wonderfully in development and testing, but takes forever to run at a few of our customer sites. In each case, some eager beaver IT guy had gone through Active Directory whacking "standard" properties that he didn't think he needed. In many IT departments, anything they don't understand is labeled as a "security risk".

    Can someone tell me what the appropriate setup for AD is to get these methods to work like they should? Can I get a list of the properties that are required?


    Mark Woodard

    Monday, October 8, 2012 1:34 PM

Answers

  • Hi Mark,

    >>But in a couple of cases, when the responses were very slow (several minutes), 

    If the customer's IT department never removing the property values, the application doesn't work at all. But once the properties been moved, the application works. Right? 

    I think you may need to check the network connection. This function may look for some information on a unreachable server. It spends a lot of time to wait the connection time out.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, October 11, 2012 8:11 AM
    Moderator

All replies

  • Hi Mark,

    Welcome to the MSDN Forum.

    Based on your description, it seems that your Domain Administrator limited some users' right on qeurying the AD. So your application cannot work well on these users' computer.

    If I am right, please try to start a new process with the domain administrator account: http://msdn.microsoft.com/en-us/library/system.diagnostics.processstartinfo.aspx 

    Assign the username, password and domain property, and then assign this to a process: http://msdn.microsoft.com/en-us/library/system.diagnostics.process.aspx  

    Or start a new thread with enough power account: http://msdn.microsoft.com/en-us/library/system.threading.thread.currentprincipal.aspx 

    And this is the sample code in the link:

        static void Main()
        {
            string[] rolesArray = {"managers", "executives"};
            try
            {
                // Set the principal to a new generic principal.
                Thread.CurrentPrincipal = 
                    new GenericPrincipal(new GenericIdentity(
                    "Bob", "Passport"), rolesArray);
            }
            catch(SecurityException secureException)
            {
                Console.WriteLine("{0}: Permission to set Principal " +
                    "is denied.", secureException.GetType().Name);
            }
    
            IPrincipal threadPrincipal = Thread.CurrentPrincipal;
            Console.WriteLine("Name: {0}\nIsAuthenticated: {1}" +
                "\nAuthenticationType: {2}", 
                threadPrincipal.Identity.Name, 
                threadPrincipal.Identity.IsAuthenticated,
                threadPrincipal.Identity.AuthenticationType);
        }

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, October 9, 2012 9:28 AM
    Moderator
  • This process occurs during a login procedure. The customer is supposed to supply the credentials of a user with enough permission to search AD. Our processes impersonate that user while searching AD. As stated before, this works well most of the time. But in a couple of cases, when the responses were very slow (several minutes), the customer's IT department admitted to messing with the standard AD setup and removing property values that they thought they didn't need. Restoring the AD setup to the original seemed to fix the problem.

    I may be completely off base, but problems like these are nearly impossible to troubleshoot at the customer site, especially since no one will tell us what is actually required in AD to use FindByIdentity to get groups or users in a timely manner.


    Mark Woodard

    Wednesday, October 10, 2012 9:37 PM
  • Hi Mark,

    >>But in a couple of cases, when the responses were very slow (several minutes), 

    If the customer's IT department never removing the property values, the application doesn't work at all. But once the properties been moved, the application works. Right? 

    I think you may need to check the network connection. This function may look for some information on a unreachable server. It spends a lot of time to wait the connection time out.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, October 11, 2012 8:11 AM
    Moderator