Re: Traveling Users Unable to Authenticate to AD

From: Al Mulnick (amulnick_No_SPAM_at_ncDOTrr.com)
Date: 03/06/05 

Date: Sun, 6 Mar 2005 13:17:31 -0500

After three successful posts, can we assume this is eating away at you? :)

Just to make sure I have it correct, you want to enable the users to
authenticate to your AD while on the NDS network and you believe that DNS is
the issue preventing this.

One question that comes to mind is what DNS server is the client machine
expected to use at any given time? Another is, if they have the ability to
use your AD infrastructure while remote, why don't they also use your DNS
servers?

It's likely that they are looking for the DC's in the myco.us.parent.com
domain on the us.parent.com name servers. You can take a network trace and
find out quickly if that's the case. But like I said, if they have the
ability to use AD for auth, why can't they use it for name resolution as
well? I'm assuming that DHCP is giving the settings to the clients on both
networks.

Al

"Scott" <Scott@discussions.microsoft.com> wrote in message
news:6AA90E78-417D-40F0-B114-E5C25D439129@microsoft.com...
> There were errors in the original post. Corrected post below:
>
> Statement of Problem:
>
> Laptop users from MYCO (on Active Directory) traveling to OTHERCO (on
> Novell
> NDS but not AD) are unable to authenticate to MYCO.US.PARENT.COM Active
> Directory.
>
> Required Result:
>
> To enable laptop users from MYCO traveling to OTHERCO to authenticate to
> MYCO.US.PARENT.COM Active Directory, get their mapped drives, access to
> file
> shares, etc. over the WAN.
>
> Background Information:
>
> Overseas parent company does not allow delegation/forwarding from/to their
> UNIX BIND 9.2 DNS servers to W2k3 Active Directory DNS;
>
> Parent company (not on Active Directory) is authoritative for DNS root
> zone:
> PARENT.COM. Neither name server records nor SOA records are allowed to be
> populated in any of the parent company-hosted DNS zones;
>
> Parent company is also authoritative 1st level DNS zone: US.PARENT.COM
> (this
> zone is hosted overseas);
>
> Our company's dual-authoritative AD-integrated and UNIX DNS zone:
> MYCO.US.PARENT.COM (from parent company perspective the UNIX servers are
> authoritative, from our company's internal client/server systems W2k3 DNS
> is
> authoritative);
>
> The W2k3 Active Directory DNS servers conditionally forward queries for
> PARENT.COM and all child domains of PARENT.COM other than
> MYCO.US.PARENT.COM
> to MYCO's UNIX BIND DNS servers. This has worked fine.
>
> Affiliated, WAN-connected US company with Novell DNS zone
> OTHERCO.US.PARENT.COM (unable to conditionally forward and not in budget
> to
> perform necessary upgrade to OS to enable this feature);
>
> Within a year, both the parent company and otherco will be migrated to a
> globally-unified Active Directory implementation in a completely different
> namespace so that this will cease to be a problem.
>
> Discussion:
>
> I believe the reason that laptop users from MYCO traveling to OTHERCO are
> unable to authenticate to MYCO.US.PARENT.COM Active Directory is that the
> OTHERCO DNS server sends packets to the US.PARENT.COM zone which looks to
> the
> UNIX BIND servers of MYCO.US.PARENT.COM for resolution-the UNIX BIND
> servers
> have the "A" records for the W2k3 DC DNS servers don't have the SRV and
> LDAP
> records necessary to enable authentication to the MYCO DC's running DNS.
>
> Without spending a lot of $$ and without having to deploy an additional
> MYCO
> DC/DNS server at otherco, we need a temporary workaround so that the
> traveling users can authenticate.
>
>
>
> "Scott" wrote:
>
>> Statement of Problem:
>>
>> Laptop users from MYCO traveling to OTHERCO (Novell NDS location with no
>> AD)
>> are unable to authenticate to MYCO.US.GRPLEG.COM Active Directory.
>>
>> Required Result:
>>
>> To enable laptop users from MYCO traveling to OTHERCO to authenticate to
>> MYCO.US.GRPLEG.COM Active Directory, get their mapped drives, access to
>> file
>> shares, etc.
>>
>> Background Information:
>>
>> Overseas parent company does not allow delegation/forwarding from/to
>> their
>> UNIX BIND 9.2 DNS servers to W2k3 Active Directory DNS;
>>
>> Parent company (not on Active Directory) is authoritative for DNS root
>> zone:
>> PARENT.COM. Neither name server records nor SOA records are allowed to be
>> populated in any of the parent company-hosted DNS zones;
>>
>> Parent company is also authoritative 1st level DNS zone: US.PARENT.COM
>> (this
>> zone is hosted overseas);
>>
>> Our company's dual-authoritative AD-integrated and UNIX DNS zone:
>> MYCO.US.PARENT.COM (from parent company perspective the UNIX servers are
>> authoritative, from our company's internal client/server systems W2k3 DNS
>> is
>> authoritative);
>>
>> The W2k3 Active Directory DNS servers conditionally forward queries for
>> PARENT.COM and all child domains of PARENT.COM other than
>> MYCO.US.PARENT.COM
>> to MYCO's UNIX BIND DNS servers. This has worked fine.
>>
>> Affiliated, WAN-connected US company with Novell DNS zone
>> OTHERCO.US.GRPLEG.COM (unable to conditionally forward and not in budget
>> to
>> perform necessary upgrade to OS to enable this feature);
>>
>> Within a year, both the parent company and otherco will be migrated to a
>> globally-unified Active Directory implementation in a completely
>> different
>> namespace so that this will cease to be a problem.
>>
>> Discussion:
>>
>> I believe the reason that laptop users from MYCO traveling to OTHERCO are
>> unable to authenticate to MYCO.US.GRPLEG.COM Active Directory is that the
>> OTHERCO DNS server sends packets to the US.PARENT.COM zone which looks to
>> the
>> UNIX BIND servers of MYCO.US.PARENT.COM for resolution-the UNIX BIND
>> servers
>> have the "A" records for the W2k3 DC DNS servers don't have the SRV and
>> LDAP
>> records necessary to enable authentication to the MYCO DC's running DNS.
>>
>> Without spending a lot of $$ and without having to deploy an additional
>> MYCO
>> DC/DNS server at otherco, we need a temporary workaround so that the
>> traveling users can authenticate.
>>
>>

Relevant Pages

  • Event Viewer Anomoly
    ... DNS operation refused. ... The File Replication Service is having trouble enabling replication ... The topology information in the Active Directory for this replica ... performed with one or more critical servers in order for changes to ...
    (microsoft.public.win2000.networking)
  • Re: Event Viewer Anomoly
    ... Please give some more infos about the kind of server, Domain controller DNS DHCP etc. and how they are located. ... The topology information in the Active Directory for this replica ... performed with one or more critical servers in order for changes to ...
    (microsoft.public.win2000.networking)
  • Re: Event Viewer Anomoly
    ... I would also make the so called "BDC" a DNS server and use Active directory ... DNS servers as preferred DNS on the NIC itself and secondary the other. ... The File Replication Service is having trouble enabling ...
    (microsoft.public.win2000.networking)
  • RE: Authentication problem on DC failure
    ... rather a dns problem. ... The client machines as well as servers need to be ... Do your clients use dhcp for their ip addresses? ... able to locate the other dc and therefore couldn't authenticate. ...
    (microsoft.public.windows.server.active_directory)
  • RE: Authentication problem on DC failure
    ... Do your clients use dhcp for their ip addresses? ... options in the dhcp scope have you configured both dc's as dns servers for ... and they locate them by looking at srv records in dns. ... able to locate the other dc and therefore couldn't authenticate. ...
    (microsoft.public.windows.server.active_directory)