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.
--
Best regards,
Andrey Repin