none
System.Runtime.InteropServices.COMException (0x8007203A)

    Question

  • Hey guys,

    I'm having a issue with one of our servers, and I'm hoping maybe one of you can help me. I have an IIS application that uses Windows Authentication, an AD user is configured to run the application pool, and the authentication works, but only if you use DOMAIN.COM\Username, if you use DOMAIN\username or just username it fails. Now you might be thinking well just use the DOMAIN.COM\Username format, but the thing is that we have a mirrored application on a different site and this one works with either of the formats, so users who work on both sites are constantly having issues by using the different format.

    Some information about the infrastructure, the server sits on one network, and the Domain Controller it connects to is an RODC on a different zone. Firewall between them but all documented Active directory ports are open between them.

    The error stack that we get is the following:

    System.Runtime.InteropServices.COMException (0x8007203A): The server is not operational.
        at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
        at System.DirectoryServices.DirectoryEntry.Bind()
        at System.DirectoryServices.DirectoryEntry.get_AdsObject()
        at System.DirectoryServices.PropertyValueCollection.PopulateList()
        at System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName)
        at System.DirectoryServices.PropertyCollection.get_Item(String propertyName)
        at System.DirectoryServices.AccountManagement.PrincipalContext.DoLDAPDirectoryInitNoContainer()
        at System.DirectoryServices.AccountManagement.PrincipalContext.DoDomainInit()
        at System.DirectoryServices.AccountManagement.PrincipalContext.Initialize()
        at System.DirectoryServices.AccountManagement.PrincipalContext.ContextForType(Type t)
        at System.DirectoryServices.AccountManagement.Principal.GetStoreCtxToUse()
        at System.DirectoryServices.AccountManagement.Principal.set_SamAccountName(String value)
    

    I've done a bit of troubleshooting on the DirectoryEntry.Bind function and found that when you call it without the domain, i.e. when we have issues, it calls itself with path "LDAP:\RootISE" which in term is suppose to find the nearest domain and 'bind' to it, but this fails.

    I hope one of you experts might have some insight on this because i'm honestly stumped.

    Thanks for your time.

    Edit: Below is a snippet of code that i put together in PowerShell to get the PrincipalContext, and DirectoryEntry classes.

    Add-type -AssemblyName System.DirectoryServices
    Add-type -AssemblyName System.DirectoryServices.AccountManagement
    
    [System.DirectoryServices.AccountManagement.PrincipalContext]::new([System.DirectoryServices.AccountManagement.ContextType]::Domain, "domain") <- Fails
    [System.DirectoryServices.AccountManagement.PrincipalContext]::new([System.DirectoryServices.AccountManagement.ContextType]::Domain, "domain.com") <- Works
    [System.DirectoryServices.AccountManagement.PrincipalContext]::new([System.DirectoryServices.AccountManagement.ContextType]::Domain) <- fails
    
    [System.DirectoryServices.DirectoryEntry]::New("LDAP://RootDSE") <- Fails
    [System.DirectoryServices.DirectoryEntry]::New() <- Fails
    Thursday, January 12, 2017 11:31 PM

Answers

  • Hey guys, thanks for those that tried to help out. I found the solution. It appears that when you call DirectoryEntry it will try to do its thing and do a RootDSE call, which is an ADSI call, and today I learned that ADSI will ignore Read Only domain controllers unless you specify to use a RODC, which a the default constructor on DirectoryEntry does not.

    Well hope this might help someone else in the future.

    • Marked as answer by Kio_ Saturday, January 14, 2017 4:11 AM
    Saturday, January 14, 2017 4:11 AM

All replies

  • Hi,
    As far as I know, when we configure the Identity for IIS application pool under domain account, we could select the custom account with the specific format:
    “Go to the application pool for the site and change the Indentity user to the domain user.  You can find this by selecting the app pool and clicking Advance Settings... under the Actions pane menu.  Select Identity and then click the button beside the current user listed.  Select Custom account and click Set.  Use the format domain\username for the username and enter the password for the user.”
    You could start for checking from this and see if all configuration is correctly set. Please see details from: https://forums.iis.net/t/1213147.aspx?How+I+can+run+IIS+app+pool+by+domain+account+
    In addition, since the question is also related to IIS, for me, I would post the questions in the IIS forum: https://forums.iis.net/
    The reason why we recommend posting appropriately is you will get the most qualified pool of respondents, and other partners who read the forums regularly can either share their knowledge or learn from your interaction with us. Thank you for your understanding.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, January 13, 2017 7:00 AM
    Moderator
  • Hey guys, thanks for those that tried to help out. I found the solution. It appears that when you call DirectoryEntry it will try to do its thing and do a RootDSE call, which is an ADSI call, and today I learned that ADSI will ignore Read Only domain controllers unless you specify to use a RODC, which a the default constructor on DirectoryEntry does not.

    Well hope this might help someone else in the future.

    • Marked as answer by Kio_ Saturday, January 14, 2017 4:11 AM
    Saturday, January 14, 2017 4:11 AM
  • Hi,
    Great share and it will be greatly helpful to others who have the same question.
    Appreciate for your feedback.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, January 17, 2017 2:22 AM
    Moderator