[Samba] Unable to contact RPC server on a new DC

[Rowland Penny]

On 11/06/2023 12:39, Andrey Repin via samba wrote:
> Hello Andrew Bartlett,
> 
> Friday, June 9, 2023, 11:25:01 PM, you wrote:
> 
>> On Thu, 2023-06-08 at 13:41 +0300, Andrey Repin via samba wrote:
>>> Greetings, All!
>>>
>>> I've added a new DC to the working AD, transferred FSMO roles
>>> (checked, all 7
>>> are ok') and (supposedly) correctly demoted the old DC.
>>>
>>> SchemaMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=
>>> InfrastructureMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=S
>>> RidAllocationMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Si
>>> PdcEmulationMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sit
>>> DomainNamingMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sit
>>> DomainDnsZonesMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=S
>>> ForestDnsZonesMasterRole owner: CN=NTDS
>>> Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=S
>>>
>>> Now, I'm unable to connect to the domain using RSAT - the error is
>>> "RPC server
>>> unavailable".
> 
>> The obvious question arises:  What is in the logs?  Are there any clues
>> in the network trace?
> 
> Since I don't know what to look for, I'd be very appreciative about any
> specific pointers.
> The only prevalent message in the logs is that it is unable to resolve SID's,
> which is, to my naive understanding, is highly confusing, since these are
> Samba's own SID's, and LDAP is up and running like nothing happened.
> 
>   [2023/06/11 13:56:01.409003,  0] ../../source4/auth/unix_token.c:95(security_token_to_unix_token)
>     Unable to convert first SID (S-1-5-21-2269650170-3990761244-2407083512-1124) in user token to >
>   [2023/06/11 13:56:01.410291,  0] ../../libcli/security/security_token.c:56(security_token_debug)
>     Security token SIDs (8):
>       SID[  0]: S-1-5-21-2269650170-3990761244-2407083512-1124
>       SID[  1]: S-1-5-21-2269650170-3990761244-2407083512-515
>       SID[  2]: S-1-1-0
>       SID[  3]: S-1-5-2
>       SID[  4]: S-1-5-11
>       SID[  5]: S-1-5-64-10
>       SID[  6]: S-1-5-32-554
>       SID[  7]: S-1-5-32-545
>      Privileges (0x          800000):
>       Privilege[  0]: SeChangeNotifyPrivilege
>      Rights (0x             400):
>       Right[  0]: SeRemoteInteractiveLogonRight
> 
> $ ldapsearch -H ldaps://dc2.ads.darkdragon.lan -b 'DC=ads,DC=darkdragon,DC=lan' '(&(objectclass=person)(objectSid=S-1-5-21-2269650170-3990761244-2407083512-1124))'
> 
> # pubserver64, Computers, ads.darkdragon.lan
> dn: CN=pubserver64,CN=Computers,DC=ads,DC=darkdragon,DC=lan
> objectClass: top
> objectClass: person
> objectClass: organizationalPerson
> objectClass: user
> objectClass: computer
> cn: pubserver64
> instanceType: 4
> whenCreated: 20180218050559.0Z
> uSNCreated: 3347
> name: pubserver64
> objectGUID:: AlKWo+jS8U6NIw1KIFprXg==
> userAccountControl: 69632
> codePage: 0
> countryCode: 0
> primaryGroupID: 515
> objectSid:: AQUAAAAAAAUVAAAA+hxIhxwv3u34LXmPZAQAAA==
> accountExpires: 9223372036854775807
> sAMAccountName: pubserver64$
> sAMAccountType: 805306369
> dNSHostName: pubserver64.ads.darkdragon.lan
> servicePrincipalName: HOST/PUBSERVER64
> servicePrincipalName: HOST/pubserver64.ads.darkdragon.lan
> objectCategory: CN=Computer,CN=Schema,CN=Configuration,DC=ads,DC=darkdragon,DC
>   =lan
> isCriticalSystemObject: FALSE
> pwdLastSet: 133276099410000000
> lastLogonTimestamp: 133306092688283500
> whenChanged: 20230607110108.0Z
> uSNChanged: 4520
> lastLogon: 133309569525625780
> logonCount: 531667
> distinguishedName: CN=pubserver64,CN=Computers,DC=ads,DC=darkdragon,DC=lan
> 
> Which looks identical comparing to sam.ldb from DC1 backup.
> 
>> I don't see any concerns in the smb.conf you post later in the thread,
>> so the normal process is to check the logs, and if no clues at that
>> point turn up the logs until there are clues.
> 
> The problem is, I followed the standard operation to the letter, and get the
> results that are far from understandable.
> Either the wiki is lacking necessary steps to perform, or setup is somewhat
> off.
> You said you see no suspicious settings, so I presume the setup is okay at
> least on the first glance.
> So, are the wiki off by a mile then? What is the exact procedure to demote the
> PDC?
> How can I confirm that there are no traces back to the old DC left in the
> database?
> I'm not demanding fast answers, mind you, all I need ATM is some help with
> diagnostics. Some specific help, not just a "look in the logs" kind.
> 
> 

It easy to explain why SID

S-1-5-21-2269650170-3990761244-2407083512-1124

isn't getting converted into a 'user token' aka UID.

This is because it is a computer, you haven't given it a uidNumber 
attribute and you are using the idmap 'ad' backend

Are you getting these errors from users that are not also computers ?

Rowland