"server not operational"

Discussion in 'ASP .Net Security' started by brian, Mar 1, 2005.

  1. brian

    brian Guest

    We have seen this in our environment historically and are trying to
    eradicate. recently, we had a big flurry of these errors. It is
    almost impossible to reproduce .. an exception gets thrown, "the server
    is not operational" and here is the code

    dirConn.DirRootAD.Username = ConvertToCorrectUserNameFormat(sUserName,
    ADConnManager.Domain)
    dirConn.DirRootAD.Password = Password
    dirConn.DirRootAD.AuthenticationType =
    AuthenticationTypes.ServerBind
    mySearcher.Filter =
    "(&(objectCategory=user)(|(sAMAccountName=" + sUserName +
    ")(userPrincipalName=" + sUserName + ")))"
    dirConn.DirRootAD =
    mySearcher.FindOne().GetDirectoryEntry()

    ....

    Finally
    If Not objDirEntry Is Nothing Then objDirEntry.Dispose()
    If Not dirConn Is Nothing Then dirConn.Dispose()




    I hear this may be due to a BUG in the .NET framework? any truth to
    that? Any suggestions would be helpful.
     
    brian, Mar 1, 2005
    #1
    1. Advertising

  2. Did you specify a server name in your path property for the root
    DirectoryEntry? If not, then you are relying on the ADSI "serverless
    binding" feature. Serverless binding allows you to infer a domain
    controller to use automatically.

    Unfortunately, serverless binding works based on the current security
    context of the thread. Specifically, it must be a domain account in order
    for it to work. In ASP.NET, you may or may not be running under a domain
    account depending on the current process account settings and the current
    impersonation settings.

    If you can specify a specific domain controller to use and that fixes the
    problem, then you know that was your problem.

    Joe K.

    "brian" <> wrote in message
    news:...
    > We have seen this in our environment historically and are trying to
    > eradicate. recently, we had a big flurry of these errors. It is
    > almost impossible to reproduce .. an exception gets thrown, "the server
    > is not operational" and here is the code
    >
    > dirConn.DirRootAD.Username = ConvertToCorrectUserNameFormat(sUserName,
    > ADConnManager.Domain)
    > dirConn.DirRootAD.Password = Password
    > dirConn.DirRootAD.AuthenticationType =
    > AuthenticationTypes.ServerBind
    > mySearcher.Filter =
    > "(&(objectCategory=user)(|(sAMAccountName=" + sUserName +
    > ")(userPrincipalName=" + sUserName + ")))"
    > dirConn.DirRootAD =
    > mySearcher.FindOne().GetDirectoryEntry()
    >
    > ...
    >
    > Finally
    > If Not objDirEntry Is Nothing Then objDirEntry.Dispose()
    > If Not dirConn Is Nothing Then dirConn.Dispose()
    >
    >
    >
    >
    > I hear this may be due to a BUG in the .NET framework? any truth to
    > that? Any suggestions would be helpful.
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 1, 2005
    #2
    1. Advertising

  3. brian

    brian Guest

    thanks for the reply Joe. We do not specify a specific controller, but
    we do that so we can get redundancy. We can't have a single point of
    failure in our environment. We do run the code under a service
    account.

    with serverless bindings, how does it work out what dc to use? Could
    it be picking a DC not on that subnet and the call is timing out?

    Based on my findings, I think the issue could be related to a memory
    leak in this call "mySearcher.FindOne().GetDirectoryEntry()" ... as it
    is a sporadic issue (maybe caused by unusual load?). One guy was
    quoted as saying "never use FindOne" as there are known issues with it.
    We used to authenticate off of a Domino directory, and we experienced
    sporadic issues like this too. However, when using domino, we did
    specify the exact server.

    its very strange error ...i used to have a monitoring service running
    to catch the error ... it would happen 1 out of every 400 calls in
    domino. we hadn't seen it in AD for the first month of operation, now
    it is an everyday occurance.
     
    brian, Mar 2, 2005
    #3
  4. Ah, perhaps it could be a memory leak. You need to be super careful with
    SDS in long running processes and make sure you religiously use the "using"
    construct on all of the disposables (DirectoryEntry, DirectorySearcher,
    SearchResultCollection). You can also use this safely on all of the
    properties that return DirectoryEntry objects as they all return new
    objects, not an object held as a member of the containing class.

    The bug in FindOne only happens if it finds nothing as it will leak the
    underlying SearchResultCollection in that case. However, I'm pretty sure
    this was fixed in the recent .NET service packs.

    Serverless binding works based on the DsGetDCName API (read it for more
    details). Essentially, it tries to find a DC in the current site that
    matches the domain of the current account. I'm not actually sure how it
    behaves in an actual fail over situation. It is supposed to just fail you
    over if you lose the connection to the DC, but this is pretty hard to test
    in practice.

    There's actually a trick with IADsObjectOptions that allows you to discover
    the current server. You can also do that by getting dnsHostName off of
    RootDSE.

    ..NET 2.0 gives you some more control over serverless binding by exposing the
    API directly through the new DomainController class in the ActiveDirectory
    namespace. Something to look forward to.

    HTH,

    Joe K.

    "brian" <> wrote in message
    news:...
    > thanks for the reply Joe. We do not specify a specific controller, but
    > we do that so we can get redundancy. We can't have a single point of
    > failure in our environment. We do run the code under a service
    > account.
    >
    > with serverless bindings, how does it work out what dc to use? Could
    > it be picking a DC not on that subnet and the call is timing out?
    >
    > Based on my findings, I think the issue could be related to a memory
    > leak in this call "mySearcher.FindOne().GetDirectoryEntry()" ... as it
    > is a sporadic issue (maybe caused by unusual load?). One guy was
    > quoted as saying "never use FindOne" as there are known issues with it.
    > We used to authenticate off of a Domino directory, and we experienced
    > sporadic issues like this too. However, when using domino, we did
    > specify the exact server.
    >
    > its very strange error ...i used to have a monitoring service running
    > to catch the error ... it would happen 1 out of every 400 calls in
    > domino. we hadn't seen it in AD for the first month of operation, now
    > it is an everyday occurance.
    >
     
    Joe Kaplan \(MVP - ADSI\), Mar 2, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.

Share This Page