locked
How can I connect to a remote domain using Active Directory Administrative Center (ADAC)? RRS feed

  • Question

  • I've got several AD forests.  Some are separated from the live network by firewalls.  I want to manage all domains in these forests using a single instance of ADAC in the live domain.  Currently, since I don't have Win7 yet, I'm running ADAC on a 2008 R2 server, let's call in MgmtSvr1.

    The various forests have 2008 DCs but not R2 DCs, so I've installed the Active Directory Management Gateway Service (ADMGS) and its prereqs.  I've tested it using ADAC from an R2 member server in the domain, so I know the Active Directory Web Service is working on the target domain controller.

    I've opened up TCP port 9389, on the firewall that separates the domains, from the MgmtSvr1 to the target DC running ADMGS.  Firewalls are currently off on the DCs in question, to facilitate testing.

    When I open ADAC on MgmtSvr1 and go to Add Navigation Nodes > Connect to other domains... and supply the IP address of the target DC, I get the error "Cannot find an available server in the 172.28.205.10 domain that is running the Active Directory Web Service (ADWS)."

    Can anyone help with this, please?

    [EDIT]

    I can access the target DC from PowerShell from MgmtSvr1, e.g. with the command: get-adrootdse -server 172.28.205.10 -credential $cred, having specified $cred = Get-Credential

    • Edited by SSG31415926 Tuesday, October 13, 2009 9:44 AM Added supporting info
    Tuesday, October 13, 2009 9:28 AM

Answers

  • Hi,

     

    As far as I know, DSAC is based on AD Powershell which requires one or more W2K8R2 DCs running Active Directory WebServices (ADWS) to function. Since ADWS is only installed on W2K8R2 or later DCs this error is expected in down-level domains containing only pre-W2K8R2 DCs.

     

    Is your destination DC a down-level domain?
    Do these forests have trust relationship and which kind of trust they are?

    ADWS listens on TCP port 9389 and is installed with the Active Directory Domain Services and Active Directory Lightweight Directory Services roles on W2K8R2.
    This port cannot be altered.

    If W2K8R2 DCs exist in the environment but DSAC generates this error the following things should be verified:

    1. Verify ADWS is started on the W2K8R2 domain controllers.
    2. Using netstat.exe verify the TCP port 9389 is being use by ADWS and that another process has not hijacked the port.

    c:\>netstat -ano

    Active Connections

    Proto Local Address Foreign Address State PID
    TCP 0.0.0.0:9389 0.0.0.0:0 LISTENING 1404

    3. Using portqury.exe or portqryui.exe on the computer where DSAC is failing try to query TCP port 9389 on a W2K8R2 DC.

    The port will fail to query with results like these below if:

    a) the targeted DC is a down-level DC
    b) a firewall is blocking communication between the client and the target DC
    c) if the ADWS service is not running on the DC

     

    Best Regards,

    Wilson Jia


    This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by Wilson Jia Tuesday, October 20, 2009 1:28 AM
    Wednesday, October 14, 2009 9:39 AM

All replies

  • Hi,

     

    As far as I know, DSAC is based on AD Powershell which requires one or more W2K8R2 DCs running Active Directory WebServices (ADWS) to function. Since ADWS is only installed on W2K8R2 or later DCs this error is expected in down-level domains containing only pre-W2K8R2 DCs.

     

    Is your destination DC a down-level domain?
    Do these forests have trust relationship and which kind of trust they are?

    ADWS listens on TCP port 9389 and is installed with the Active Directory Domain Services and Active Directory Lightweight Directory Services roles on W2K8R2.
    This port cannot be altered.

    If W2K8R2 DCs exist in the environment but DSAC generates this error the following things should be verified:

    1. Verify ADWS is started on the W2K8R2 domain controllers.
    2. Using netstat.exe verify the TCP port 9389 is being use by ADWS and that another process has not hijacked the port.

    c:\>netstat -ano

    Active Connections

    Proto Local Address Foreign Address State PID
    TCP 0.0.0.0:9389 0.0.0.0:0 LISTENING 1404

    3. Using portqury.exe or portqryui.exe on the computer where DSAC is failing try to query TCP port 9389 on a W2K8R2 DC.

    The port will fail to query with results like these below if:

    a) the targeted DC is a down-level DC
    b) a firewall is blocking communication between the client and the target DC
    c) if the ADWS service is not running on the DC

     

    Best Regards,

    Wilson Jia


    This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by Wilson Jia Tuesday, October 20, 2009 1:28 AM
    Wednesday, October 14, 2009 9:39 AM
  • I know ADWS is running on the server in question because ADAC on an R2 member-server in the same domain can access it.  But I've run through your questions, anyway:

    Is your destination DC a down-level domain?
        - It is a mixture of 2003 and 2008 RTM domain controllers but I've installed the Active Directory Management Gateway Service (which provides the Active Directory Web Service for 2003 or 2008 RTM machines) on one of the 2008 DCs.

    Do these forests have trust relationship and which kind of trust they are?
        - No, there's no trust relationship between these forests.  The domains are on different networks and separated by a firewall.  I've opened up TCP 9389.  There's no DNS link between them, hence my using the IP address of the DC with the ADMGS installed.

    1. Verify ADWS is started on the W2K8R2 domain controllers.

    C:\Users\admin1>net start
    These Windows services are started:

       Active Directory Web Services
       etc.

    2. Using netstat.exe verify the TCP port 9389 is being use by ADWS and that another process has not hijacked the port.

    netstat -ano:
    TCP    0.0.0.0:9389           0.0.0.0:0              LISTENING       1456

    and, having started up ADAC on a server (server47) in the same domain:
    TCP    172.28.205.10:9389     server47:49243     ESTABLISHED    1456
    TCP    172.28.205.10:9389     server47:49245     ESTABLISHED    1456

    PID 1456 is Microsoft.ActiveDirectory.WebServices.exe (from Task Manager).
     
    3. Using portqury.exe or portqryui.exe on the computer where DSAC is failing try to query TCP port 9389 on a W2K8R2 DC.  These are the results from PortQryUI:


    =============================================

     Starting portqry.exe -n 172.28.205.10 -e 9389 -p TCP ...


    Querying target system called:

     172.28.205.10

    Attempting to resolve IP address to a name...


    IP address resolved to test.domain.local

    querying...

    TCP port 9389 (unknown service): LISTENING
    portqry.exe -n 172.28.205.10 -e 9389 -p TCP exits with return code 0x00000000.

    So, everything looks in order, except for ADAC's ability to connect.

    Tuesday, October 20, 2009 5:17 PM
  • Hi SSG,

     

    Based on my tests, the error message you are experiencing is expected in the forests without trust.

    After you create the forest trusts between those Windows 2003 forests and Windows 2008 R2 forest, you should be able to manage the multi-forest AD from Windows Server 2008 R2’s ADAC.

     

    For your information, To create a forest trusts between 2 forests, you need to create the DNS forwards in both DNS server first.

     

    In Windows 2003 DNS, you can right click the DNS server name and go to Forwarders Page.

    Add the DNS Domain name and it’s Forwarders’s IP address (Trust Forest DNS server IP address).

     

    In Windows 2008 DNS, you may go to the Conditional Forwarders in the DNS manager.

    Right click the right panel and add the DNS Domain name and it’s Forwarders’s IP address (Trust Forest DNS server IP address).

     

    Then follow the below link to create a forest trust.

    http://technet.microsoft.com/en-us/library/cc778851(WS.10).aspx

     

    After the forest trust has been created successfully, Open ADAC on MgmtSvr1, go to Add navigation Nodes > Connect to domains.

    Type in your target domain name again. Is it working now?

     

    Hope it will be helpful.

     

    Best Regards,

    Wilson Jia


    This posting is provided "AS IS" with no warranties, and confers no rights.
    • Proposed as answer by Wilson Jia Wednesday, October 21, 2009 11:24 AM
    Wednesday, October 21, 2009 11:23 AM
  • I'm afraid that creating a trust between these forests is not an option.  Some are test forests, some are in DMZs, some are 'Crash and Burn'.  No permanent links between them are acceptable.  We don't even link DNS, that's why I'm accessing the dc by IP address.
    Wednesday, October 21, 2009 1:06 PM
  • Hi SSG,

    To authenticate user logon other forests, you need to create forest trusts. Based on my tests, it works after I build the forest trust between two forests.

    However, The "Connect to" option is used to connect to a DOMAIN NAME, when I type in the DC ip address, it doesn't work for me either.

    Best Regards,
    Wilson Jia
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, October 22, 2009 4:30 AM
  • Ah, you're telling me there's no capacity to supply credentials?  I was expecting, once ADAC had connected to the new domain, that I'd have to supply creds. 

    I wonder if the guys at Microsoft EVER ask users for their requirements.

    Thursday, October 22, 2009 10:05 AM