Re: Re-Post - "the trust relationship between this workstation and





"Herb Martin" wrote:

"Server Guy" <ServerGuy@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:85CBBBA3-6A67-4311-8F96-95924C80B26B@xxxxxxxxxxxxxxxx
Hi,

I have a big problem I sure could use some help with!
This was previously posted but the thread got really long. I tried to
repost only the relative info.

When I try to add a new user account at a workstation joined to a
domain, I get an error saying I can't add the user because

"the trust relationship between this workstation and the primary domain
failed ".

This is ocurring on stations that are working fine otherwise. The
only problem is adding a new user account on the station. Existing
accounts
on the stations are working fine.

Ok, let's straighten out the terminology before you spend another 20
messages just getting the details set: You don't add a DOMAIN account
"on the station", that would be a local computer account. So if you are
adding an account locally then you must be a LOCAL ADMINISTRATOR.

If you HAD READ all of the posts you should have been able to comprehend
what I was saying. It's not all my fault there. In the previous post, yes
it was toooo long because you were fixated on it being a GNS problem
eventhough it was and had always resolved both internally/externally. Maybe
if you made your questions clearer, everyone here would bennifit.

Yes, as I had said many times before I know I was logged in as a LOCAL
ADMINISTRATOR.







If this is really * the case then perhaps you are logged on with a domain
account
that is in the Domain Admins and thereby getting Administrator privileges on
the
local machine -- but that authentication is failing? Otherwise the DOMAIN
has
nothing to do with adding an account LOCALLY to that machine.

The DOMAIN DID have everything to do with this problem. You cant tell me
that it doesnt if I have to leave the domain add the local user then rejoin
the DOMAIN.



You may add a domain account FROM a station IF you have installed the
AD management tools, i.e., AdminPak.MSI there.

For adding DOMAIN accounts to work OR for using a domain account
with local admin privileges a few things must be true:

1) Your User account must be authenticated with the domain, and that
means you are authenticating the computer account there
correctly
as well.

2) Your user account must have sufficient privileges, e.g., be an Domain
Admin, or have the Explicit RIGHT to add users (e.g., Account
Operators),
or have enough PERMISSIONS in some specific OU.

3) Name resolution must succeed so you can find the DC to which you
connect

4) Your account on that DC must be fully replicated from the DC where
you
authenticated (OR your password/credentials might not be accepted.)

5) The tools must be the correct version for the workstation (XP needs
2003
AdminPak, 2000 needs 2000 AdminPak -- the last I checked -- and you
might need to update these with current service pack versions.

6) RPCs must not be filtered by firewalls -- either the built-in
firewalls, or
add-ons like ZoneAlarm, or intermediate firewalls on routers
between
the machines.

7) Other protocols (DNS, DS, etc) must not be filtered but #6 RPCs were
mentioned separately since you indicate most things are working
correctly.

8) Any trusts involved must work, but here I am generally assuming a
single
domain.

As I listed, yes, a single domain with only 1 DC/DNS box



9) The computer account is hosed in AD, but you have already reset the
computer account.

10) The DNS Zone for your AD Domain must be DYNAMIC, with the
DC(s) properly registered on all DNS servers which hold the
zone.
This would be on the DNS server 172.20.100.2


DNS was and is working fine.



All of the above are things to check explicitly; some are elaboted below.

For #1, the computer & user accounts to authenticate the DCs must be
findable
(fully) in DNS, this means it must be fully registered (DCDiag /c wiith no
FAIL
or WARN should do).

Client computer must use STRICTLY the INTERNAL DNS server which can
resolve the DC. DC is a DNS client too, and this rule applies to it too.

AGAIN, DNS is FINE!!!



The time on the local computer and DC must be WITHIN 5 minutes (by default)
in Universal time. So check time AND make sure both DC and station TIMEZONE
are correct set, otherwise the time may look right but be an hour or hours
off.


Not it either



If I add an existing account to a different station, same result.
Tried setting up a new account in AD. Same error when adding account to
station.

* Why do you keep saying "at" a different station, or "to" a local machine?
Are you really adding LOCAL accounts?



Yes, as I have said numerous times, tried this at several workstations to
add a local account while the workstatione is a member of the domain.






If so, you should test that by trying to logon as the LOCAL ADMIN and see
if it then works. If so, you have a problem (perhaps) with the domain
authentication,
if not, you have a local problem and might need to do a REPAIR install or
otherwise
correct the local machine -- the domain is not then involve AT ALL.


Not a local machine if ALL are affected as I have previously stated.



I get the error when I go to Control panel/Users/Add User/Enter User Name
and Domain, then get "the trust
relationship between this workstation and the primary domain failed "
message

I also a Kerberos failed message from the workstation NetDiag, is this a
problem here as well?

Yes, check TIME and ESPECIALLY TIMEZONE. Say timezone is set
1 zone away; and DC and workstation LOOK correct, they are really out
of sync by an ENTIRE hour.

Wasnt the problem.


What I have to do to add the user is leave the domain, login as
administrator add the local user and make it a member of the local
administrator group, join the domain.

Ok, you really are trying to add to the WORKSTATION -- I doubt that
has ever been really clear in your posts.


Perhaps you should read more carefully before posting a reply. As in the
previous thread, you asked for thing that were already posted. This tells me
you were NOT reading the posts fully.



While this does get the user in the system, I need to make this user a
local
administrator but they only have limited rights eventhough they show as
being
a member of the local administrator group. We have 3rd party software
requireing them to be local administrators.

That software should be replaced OR the reason tracked down and explicit
rights or permission to files or registry keys granted.

Maybe so but this is the reason these threads get so long, unnecessary
comments. That has NOTHING to do with the immediat issue. It's something
that could me mentioned afeter the result is found instead of making matters
worse trying to "get around" the problem by fixing the symptom instead of the
cause.



Herb, this had absoutly nothing to do with DNS as I thought from the
beginning. Everything was resolving both internally and externally. Perhaps
if you had read the information fully and not got caught up in picking at
terminology, We could have solved it here. I would tell you what it was but
you wouldnt believe it anyway and still have me chasing DNS problems that are
not there.







I'm not sure when the problem first ocurred,but users already on the
workstations are working fine.
This is causing major issues of not being able to setup new accounts on
workstations. Big Problem!

--END OF COMMENTS--

Thanks in advance!!!

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

I included:
IPConfig /all for DC/DNS & Workstation
NetDiag for DC/DNS & workstation
NSLookup from workstation
NLTest
====================================

Lan configuration:
Single DC/DNS server Win2k SP4 server 172.20.100.2
Member Win2003 SP1 server 172.20.100.4
50-nodes: 2-W2k SP4 rest are XP-Pro SP2
USR Router used for Internet access 172.20.100.200
DNS Forwarder to 172.20.100.200
"." zone removed from Forwarder
====================================

What I have tried:
Resetting computer object in AD

Removing the computer object from AD, renaming the workstation &
re-joining
but that didn't
help.


C:\>nltest /sc_reset:contoso.org
Flags: 30 HAS_IP HAS_TIMESERV
Trusted DC Name \\server1.ABC.org
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

C:\>nltest /sc_verify:contoso.org
Flags: b0 HAS_IP HAS_TIMESERV
Trusted DC Name \\server1.ABCc.org
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully





====================================
NSLookup from Workstation
====================================
C:\Program Files\Support Tools>nslookup server1 172.20.100.2
Server: server1.contoso.org
Address: 172.20.100.2

Name: server1.contoso.org
Address: 172.20.100.2

C:\Program Files\Support Tools>
C:\Program Files\Support Tools>nslookup www.google.com 172.20.100.2
Server: server1.contoso.org
Address: 172.20.100.2

Non-authoritative answer:
Name: www.l.google.com
Addresses: 216.239.37.99, 216.239.37.104
Aliases: www.google.com

C:\Program Files\Support Tools>
C:\Program Files\Support Tools>nslookup www.google.com 172.20.100.200
Server: usr8200.home
Address: 172.20.100.200

Non-authoritative answer:
Name: www.l.google.com
Addresses: 216.239.37.104, 216.239.37.99
Aliases: www.google.com


C:\Program Files\Support Tools>
C:\Program Files\Support Tools>nslookup www.google.com 209.143.0.10
Server: primary.dns.bright.net
Address: 209.143.0.10

Non-authoritative answer:
Name: www.l.google.com
Addresses: 216.239.37.99, 216.239.37.104
Aliases: www.google.com


====================================
IPConfig - Workstation
====================================
Windows IP Configuration
Host Name . . . . . . . . . . . . : RM-7-1
Primary Dns Suffix . . . . . . . : contoso.org
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 172.20.7.1
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 172.20.100.200
DNS Servers . . . . . . . . . . . : 172.20.100.2


====================================
IPConfig - DC/DNS Server
====================================
Host Name . . . . . . . . . . . . : server1
Primary DNS Suffix . . . . . . . : contoso.org
Node Type . . . . . . . . . . . . : Broadcast
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : contoso.org

IP Address. . . . . . . . . . . . : 172.20.100.2
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 172.20.100.200
DNS Servers . . . . . . . . . . . : 172.20.100.2



====================================
NetDiag - Workstation
====================================


Gathering the list of Domain Controllers for domain 'contoso'
Testing trust relationships... Passed
Testing Kerberos authentication... Failed
Testing LDAP servers in Domain contoso ...

Tests complete.
Default gateway test . . . : Passed
Pinging gateway 172.20.100.200 - reachable
At least one gateway reachable for this adapter.

Domain membership test . . . . . . : Passed
Machine is a . . . . . . . . . : Member Workstation
Netbios Domain name. . . . . . : contoso
Dns domain name. . . . . . . . : contoso.org
Dns forest name. . . . . . . . : contoso.org
Domain Guid. . . . . . . . . . : {437C8357-82E5-44BB-87EC-FB3DE7E91058}
Domain Sid . . . . . . . . . . :
S-1-5-21-1838114092-1579624115-538272213
Logon User . . . . . . . . . . : Administrator
Logon Domain . . . . . . . . . : contoso
Logon Server . . . . . . . . . : \\server1

DNS test . . . . . . . . . . . . . : Passed
Interface {7723A855-721E-4C55-B595-814BDDE90AE5}
DNS Domain:
DNS Servers: 172.20.100.2
IP Address: 172.20.7.1
.



Relevant Pages

  • Re: Re-Post - "the trust relationship between this workstation and the
    ... "the trust relationship between this workstation and the primary domain ... only problem is adding a new user account on the station. ... Client computer must use STRICTLY the INTERNAL DNS server which can ... Attr: subschemaSubentry ...
    (microsoft.public.windows.server.active_directory)
  • Re: Re-Post - "the trust relationship between this workstation and
    ... account is NEW to the workstation. ... needs admin group priv at workstation level. ... only problem is adding a new user account on the station. ... This would be on the DNS server 172.20.100.2 ...
    (microsoft.public.windows.server.active_directory)
  • Re: Re-Post - "the trust relationship between this workstation and
    ... There were no logged events in either the DC or workstation. ... DC/DNS Server - DCDiag ... Attr: subschemaSubentry ... only problem is adding a new user account on the station. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Number of GC servers
    ... Are you using the Restricted Groups GPO?? ... That might give you an indication as to why labserver works on one server ... DNS is handled by corporate servers. ... If I logon to cmpq02,cmpq04, as "labserver" (a generic account, that is ...
    (microsoft.public.windows.server.active_directory)
  • Re: AD Newbie Questions
    ... Remember that though DNS and AD are ... You can copy the profile over, either doing a straight copy (get the ... > I've reviewed a few books on Server2K3, but before I> promote my server to a Domain Controller, there are still a few specifics> where I'd appreciate some guidance. ... I would install Studio.NET on the XP Pro workstation. ...
    (microsoft.public.windows.server.active_directory)