Advanced server can't talk to DC of trusted domain

[H_Bachner]

OpenVMS V7.3-2, Advanced Server V7.3A ECO 4

Advanced Server is a member in an AD domain which has two-way trusts defined to a few other (mostly AD-)domains. ADMIN SHOW TRUST shows these correctly.

When I try to add permissions to a share for a user group of a trusted domain, Advanced Server (apparently) needs to get the SID of that group from a domain controller of the trusted domain.

This used to work previously - so they say :-)

Today AS claimed that it could not find the PDC of the trusted domain. KNBDAEMON logged a message that name lookup in LMHOSTS for the domain name with the [1b] suffix (domain master browser --> PDC emulator) failed.

I added the PDC emulator name and address along with the domain name with \x1b and \x1c suffixes to LMHOSTS (with the usual #PRE and #DOM additions). Still got the KNBDAEMON errors, the new addresses were not added to the KNB name cache.

After a restart of Advanced Server the addresses showed up in the KNB name cache (permanently) but setting the permission (or just a ADMIN SHO COMPUTER /DOM:trusted-dom, which also needs to contact the PDC) did not work. No more error messages in the KNBDAEMON log.

$ nbshow knbstatus pdc-emul
$ nbshow knbstatus trusted-dom 1b

worked just fine and instantly delivered the name list associated with the pdc emulator. So why would ADMIN SHOW COMPUTER /DOM:trusted-dom still fail with the message that it could not find the PDC? (after running into some timeout).

Any ideas what's happening here? And how to fix it?

Thanks for all and any help,
Hans.

[Karl Rohwedder]

We have had those problems too, often something changed on the windows- or network side.
The V7.3B releasenotes contain some hints about PDC's being accessed over a WAN leading to timeouts...If that's the case, there is registry vaiable memberinAD, which might help.

As always, try the latest version, it's V7.3B-PS014. You can get it here:
ftp://hprc.external.hp.com/asv/ [pathwork/support]

regards kalle

[Paul Nunez · Accepted solution]

Hi Hans,

Since name resolution has been eliminated as a source of the problem, it's likely a security policy setting on the AD domain controller that is preventing Advanced Server from accessing it.

Depending on your access to the PDC emulator of that domain, you could either review the policies and see if you can locate the offender or get a trace on the Advanced Server and look at the trace for the failure.

Security policies such as "Network security: Lanman authentication level" or "Network access: Anonymous access to named pipes and shares" would be of concern.

To get a trace use:

$ @sys$startup:tcpip$define_commands
$ spawn/nowait/notify tcpdump -s 1518 -w outputfile.cap host

Use Ctrl+C (not Ctrl+Y) to stop the trace after reproducing the error. Wireshark is the tool of choice for analyzing the capture file. For example, if you see the failure occurs when Advanced Server tries to open \srvsvc, that's the Server Service named pipe, so "Network access: Restrict anonyomous access to named pipes and shares" is probably enabled.

It's ok to enable that policy as long as they add several named pipes to the policy "Network access: Named pipes that can be accessed anonymously", including:

srvsvc
lsarpc
wkssvc
netlogon
samr

Using MemberInAD won't help when it comes to ADMIN commands (it only affects the NETLOGON secure channel establishment when Advanced Server member server starts; with it set, Advanced Server won't specifically seek out the domain PDC when establishing the secure channel - it will instead seek out any domain controller by querying for the domainname\0x1c name instead of domainname\0x1b - with the expectation that the first response will come from the "nearest" DC, which may or may not be the PDC).

On the other hand, I could be completely wrong :O). But a network trace will eliminate the guess work.

Best regards,

Paul

[H_Bachner]

Kalle,

thanks for your sugestions.

> We have had those problems too, often something changed on the
> windows- or network side.

I suspect that the problem lies there. In the meantime I heared that all the Windows servers had been rebooted prior to the problem showing up.

> The V7.3B releasenotes [...] If that's the case, there is registry
> variable memberinAD, which might help.

IIRC this registry key is already set, because Advanced Server is a member server in an AD domain. The problem is seen with the DC of a trusted domain.

Thanks & regards,
Hans.

[H_Bachner]

Hi Paul,

many thanks for the detailed troubleshooting instructions :-) and the additional info regarding memberinAD.

There were some general network problems on Friday, and I'll be on the road on Monday, so I'll continue to pursue this problem on Tuesday. I'll report back here asap.

Best regards,
Hans.

[H_Bachner]

Well... some time has passed since I opened this thread.

I took a trace as Paul suggested but in the limited time I had available to analyze the problem I did not get very far with that.

But...
yesterday another problem popped up. After
$ admin login
I was unable to look at various things, like
$ admin show share /full

Advanced Server kept asking for a password for the (local) member server. I could still find/contact the PDC emulator and other "1c" servers in the domain, logon seemed to work (administrative status was acknowledged) but when I tried admin commands like "show session" or even "show admin" I only got "Password for server NODNAM:".

I shut down Advanced Server and ran samcheck:

$ samcheck -s -v
The domain name in the policy object is incorrect.

1 miscellaneous problems were found.
The command failed.
$

So I decided to remove the local SAM database and run PWRK$CONFIG to recreate it (restored SHAREDB. and ACL. after that).
[Would there have been another way to fix the SAM database?]
Restarted Advanced Server, all admin commands worked fine again.

And guess what: the PDC of the trusted domain (the problem which initiated this thread) could be accessed again!

So the customer is happy again, and I still have the trace file spinning around on a disk and hope to find some time soon to take a closer look. I'm still curious about the cause of the original problem...