[Samba] Unable to contact RPC server on a new DC
rpenny at samba.org
Sun Jun 11 14:49:29 UTC 2023
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
>>> InfrastructureMasterRole owner: CN=NTDS
>>> RidAllocationMasterRole owner: CN=NTDS
>>> PdcEmulationMasterRole owner: CN=NTDS
>>> DomainNamingMasterRole owner: CN=NTDS
>>> DomainDnsZonesMasterRole owner: CN=NTDS
>>> ForestDnsZonesMasterRole owner: CN=NTDS
>>> Now, I'm unable to connect to the domain using RSAT - the error is
>>> "RPC server
>> 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
> 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
> 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
> How can I confirm that there are no traces back to the old DC left in the
> 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
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 ?
More information about the samba