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



"Al Mulnick" wrote:

Interesting. I read it that he was adding domain user accounts to the local
machine, but now that you put it like that.....
ServerGuy, can you clarify what you are doing as Herb has asked?

Adding a local user to a workstation(that's also joined to the domain). The
account is NEW to the workstation. Account gets restricted access in AD but
needs admin group priv at workstation level. Worked in the past.


Also, what is with the nslookup query? Why go to that trouble? Just start
nslookup and which server answers for the client, use that to find the
domain? For example:
nslookup
domain.com
You should get back a list. Do you?

Oh, and this:
[FATAL] Kerberos does not have a ticket for
host/RM-7-1.contoso.org

That's a problem that you need to deal with and is likely at the heart of
the issues you see. Or at least, if you resolve that issue, you may find
that your other issues go away.

The Kerberos issue is something I brought up several times but have not
gotton a good response from yet other than checking time/date between the
DC/DNS & the workstation. That's fine now but same problem. Information I
have found searching is pretty vague. I'm open to suggestions here.



While at it, can you also check your netbios resolution and reverse
resolution especially of the workstations that are experiencing the issues?

ALL workstations are experiencing the same problems.



Al



"Herb Martin" <news@xxxxxxxxxxxxxx> wrote in message
news:eCZcIqMTHHA.2256@xxxxxxxxxxxxxxxxxxxxxxx
"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 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.

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.

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

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.

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.


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?

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.


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.

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.

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.

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



.

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
    ... 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: Re-Post - "the trust relationship between this workstation and
    ... There is no secondary WINS server defined for this adapter. ... Can you also run netdom and verify that the workstation has a valid ... account and that it checks out ok? ... Attr: subschemaSubentry ...
    (microsoft.public.windows.server.active_directory)
  • 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. ... This would be on the DNS server 172.20.100.2 ... Attr: subschemaSubentry ...
    (microsoft.public.windows.server.active_directory)
  • AD Newbie Questions
    ... on the workstation, but I would prefer, if possible, to set up a genuine ... server/database server. ... The XP Pro workstation already has a local user account with a ... added the computer to the domain, I'd like to copy the local profile to ...
    (microsoft.public.windows.server.active_directory)