[Samba] Unable to contact RPC server on a new DC
Andrey Repin
anrdaemon at yandex.ru
Mon Nov 6 17:31:49 UTC 2023
Greetings, Rowland Penny via samba!
> On 08/06/2023 13:53, Andrey Repin via samba wrote:
>> Hello Rowland Penny,
>> > Thursday, June 8, 2023, 2:10:39 PM, you wrote:
>> > > >> On 08/06/2023 11:41, 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".
>>>>> Tried to forcefully remove old DC from the new one, just to be sure. It did
>>>> some additional cleanup, judging by the wall of debug messages, but that did
>>>> not help in the slightest.
>>>> Googled a bug https://bugzilla.samba.org/show_bug.cgi?id=12534 and manually
>>>> removed the last DNS record.
>>>> Now the DNS check reporting only new DC, but it is still not working like it
>>>> should.
>>>>> So far, I've made these checks:
>>>>> I can impersonate domain users and login with SSH using domain users on
>>>> domain members, even new logins with homedir creation, but…
>>>>> Domain users/groups listing works partially.
>>>>> One member:
>>>> groups: cannot find name for group ID 10008
>>>> groups: cannot find name for group ID 10009
>>>> groups: cannot find name for group ID 10010
>>>> # getent group | grep -P "1\\d{4}"
>>>> domain sudoers:x:10006:
>>>> domain admins:x:10000:
>>>> domain users:x:10001:
>>>> cvs:x:10005:
>>>>> Another member:
>>>>> # getent group | grep -P "1\\d{4}"
>>>> domain computers:x:10003:
>>>> domain sudoers:x:10006:
>>>> domain admins:x:10000:
>>>> domain guests:x:10002:
>>>> cloud admins:x:10010:
>>>> domain users:x:10001:
>>>> remote users:x:10009:
>>>> cloud users:x:10008:
>>>> git admins:x:10007:
>>>> cvs:x:10005:
>>>>> Even wbinfo lists groups/users incorrectly on different machines.
>>>>> anrdaemon at pubserver64:xterm:~
>>>> $ wbinfo -g | wc -l
>>>> 20
>>>> anrdaemon at hosting64:xterm:~
>>>> $ wbinfo -g | wc -l
>>>> 18
>>>>> anrdaemon at daemon1:screen&0:~
>>>> $ wbinfo -u | wc -l
>>>> 12
>>>> anrdaemon at hosting64:xterm:~
>>>> $ wbinfo -u | wc -l
>>>> 11
>>>>> Domain authorization works… not.
>>>>> anrdaemon at hosting64:xterm:~
>>>> $ sudo -iH
>>>> [sudo] password for anrdaemon:
>>>> Sorry, try again.
>>>> sudo: 1 incorrect password attempt
>>>>> anrdaemon at pubserver64:xterm:~
>>>> $ sudo -iH
>>>> [sudo] password for anrdaemon:
>>>> Domain Controller unreachable, using cached credentials instead.
>>>> Network resources may be unavailable
>>>>> At the same time LDAP works like a charm and top-level tests pass
>>>>> # net ads testjoin
>>>> Join is OK
>>>>> # net ads info
>>>> LDAP server: 192.168.1.19
>>>> LDAP server name: dc2.ads.darkdragon.lan
>>>> Realm: ADS.DARKDRAGON.LAN
>>>> Bind Path: dc=ADS,dc=DARKDRAGON,dc=LAN
>>>> LDAP port: 389
>>>> Server time: Вс, 07 май 2023 18:03:26 MSK
>>>> KDC server: 192.168.1.19
>>>> Server time offset: 0
>>>>> But…
>>>>> # wbinfo -t
>>>> checking the trust secret for domain DARKDRAGON via RPC calls failed
>>>> wbcCheckTrustCredentials(DARKDRAGON): error code was
>>>> NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233)
>>>> failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR
>>>> Could not check secret
>>>>> And DC log is spammed with messages like
>>>>> : [2023/05/07 18:05:49.693988, 0]
>>>> ../../source4/auth/unix_token.c:95(security_token_to_unix_toke>
>>>> : Unable to convert first SID
>>>> (S-1-5-21-2269650170-3990761244-2407083512-1106) in user token to>
>>>> : [2023/05/07 18:05:49.694080, 0]
>>>> ../../libcli/security/security_token.c:56(security_token_debug)
>>>> : Security token SIDs (8):
>>>> : SID[ 0]: S-1-5-21-2269650170-3990761244-2407083512-1106
>>>> : 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
>>>>> DC smb.conf attached, if needed.
>> >> No it wasn't, this list strips attachments.
>> > Good for a list, I suppose, but bad for people using it.
>> >>>> I have a full offline backup of both DC's prior to transfer and already tried
>>>> to redo the process, but to the same effect.
>>>>> So, what can I do now?
>>>>> ----------
>>>>> Update since the original message failed to be delivered to the list,
>>>> and a month passed already:
>>>> Now, even DC is unable to confirm its connection to the domain.
>>>>> (DC2)root at dc2:screen:~
>>>> # net ads testjoin
>>>> kerberos_kinit_password DARKDRAGON at ADS.DARKDRAGON.LAN failed: Client
>>>> not found in Kerberos database
>>>> Join to domain is not valid: The name provided is not a properly
>>>> formed account name.
>>>>> The question remains the same: what can I do now? Short of restarting
>>>> the entire domain.
>>>> What checks can I run to see where the culprit is, and how I can cure it?
>>>>>
>>> Can we please see the smb.conf from a DC and from a Unix domain member.
>> >>> DC:
>> > # Global parameters
>> [global]
>> auto services = homes
>> client ldap sasl wrapping = sign
>> dns forwarder = 192.168.1.12
>> dos charset = CP866
>> logging = systemd
>> log level = 1
>> netbios name = DC2
>> panic action = /usr/share/samba/panic-action %d
>> printcap name = /dev/null
>> realm = ADS.DARKDRAGON.LAN
>> server role = active directory domain controller
>> template homedir = /home/%U
>> template shell = /bin/bash
>> tls enabled = Yes
>> tls priority = NORMAL:-VERS-SSL3.0:+VERS-TLS-ALL
>> winbind enum groups = Yes
>> winbind enum users = Yes
>> winbind nss info = rfc2307
>> winbind offline logon = Yes
>> winbind refresh tickets = Yes
>> winbind use default domain = Yes
>> workgroup = DARKDRAGON
>> idmap config darkdragon : unix_nss_info = yes
>> idmap config darkdragon : unix_primary_group = yes
>> idmap config darkdragon : range = 2048-131071
>> idmap config darkdragon : schema_mode = rfc2307
>> idmap config darkdragon : backend = ad
>> idmap config * : range = 1024-2047
>> idmap config * : schema_mode = rfc2307
>> idmap config * : backend = tdb
>> idmap_ldb : use rfc2307 = Yes
>> map acl inherit = Yes
>> store dos attributes = Yes
>> vfs objects = dfs_samba4 acl_xattr
>> > [netlogon]
>> comment = Network Logon Service
>> csc policy = disable
>> path = /var/lib/samba/sysvol/ads.darkdragon.lan/scripts
>> read only = No
>> > [sysvol]
>> comment = Domain System Volume
>> csc policy = disable
>> path = /var/lib/samba/sysvol
>> read only = No
>> >>> Member server:
>> > # Global parameters
>> [global]
>> dos charset = CP866
>> workgroup = DARKDRAGON
>> realm = ADS.DARKDRAGON.LAN
>> netbios name = DAEMON1
>> interfaces = lo mac0
>> bind interfaces only = Yes
>> security = ADS
>> dedicated keytab file = /etc/krb5.keytab
>> kerberos method = secrets and keytab
>> log level = 1
>> server min protocol = NT1
>> min protocol = NT1
>> client min protocol = NT1
>> client ldap sasl wrapping = sign
>> printcap name = /dev/null
>> preferred master = Yes
>> local master = Yes
>> domain master = Yes
>> browse list = Yes
>> wins server = 127.0.0.1
>> wins support = Yes
>> preload = homes
>> auto services = homes
>> panic action = /usr/share/samba/panic-action %d
>> winbind enum users = Yes
>> winbind enum groups = Yes
>> winbind use default domain = Yes
>> winbind nss info = rfc2307
>> winbind refresh tickets = Yes
>> winbind offline logon = Yes
>> client ipc min protocol = NT1
>> idmap config darkdragon : unix_nss_info = yes
>> idmap config darkdragon : unix_primary_group = yes
>> idmap config darkdragon : range = 2048-131071
>> idmap config darkdragon : schema_mode = rfc2307
>> idmap config darkdragon : backend = ad
>> idmap config * : range = 1024-2047
>> idmap config * : backend = tdb
>> map acl inherit = Yes
>> store dos attributes = Yes
>> vfs objects = acl_xattr
>> > [netlogon]
>> comment = Network Logon Service
>> path = /home/.samba/netlogon
>> read only = No
>> csc policy = disable
>> > [homes]
>> comment = Home Directory
>> path = /home/%S
>> valid users = %S
>> read only = No
>> browseable = No
>> csc policy = disable
>> follow symlinks = No
>> > [printers]
>> comment = All Printers
>> path = /var/spool/samba
>> printable = Yes
>> browseable = No
>> csc policy = disable
>> > [print$]
>> comment = Printer Drivers
>> path = /var/lib/samba/printers
>> > [arc]
>> comment = Software archive
>> path = /srv/arc
>> read only = No
>> browseable = No
>> csc policy = disable
>> >
> OK, you have these lines on the DC:
> winbind nss info = rfc2307
> winbind use default domain = Yes
> idmap config darkdragon : unix_nss_info = yes
> idmap config darkdragon : unix_primary_group = yes
> idmap config darkdragon : range = 2048-131071
> idmap config darkdragon : schema_mode = rfc2307
> idmap config darkdragon : backend = ad
> idmap config * : range = 1024-2047
> idmap config * : schema_mode = rfc2307
> idmap config * : backend = tdb
> Why ? They do nothing on a DC.
> Why do you have 'auto services = homes' without actually having a 'homes' share ?
> Turning to the Unix domain member, why are you using SMBv1 aka 'NT1', the DC isn't
Because DC1 used it. Consider it a legacy. Why would Win7 (RSAT) do not
connect? THAT is the main question.
> Why do you have a netlogon share on the Unix domain member ?
An oversight, I presume. (it's the baremetal host, on which I ran some
experiments in the past)
> Why are you using Wins ? AD does not use Wins, it uses DNS.
I tried to normalize network discovery. IT's VERY slow ATM. Minutes to get a
list of hosts in a workgroup.
> Why do you have this line: 'idmap config * : schema_mode = rfc2307'
Why not?
> Finally, you have the 'winbind enum' lines set to yes on both machines,
I tried to normalize network discovery. See above.
> this should only be done for testing purposes, Samba will quite correctly without the lines.
If these settings are irrelevant for their respective placement, you could
have just stated that instead of an extensive questioning.
I appreciate your attention, though. I'll meditate on these settings again,
once the system is up and running.
> When you created your new DC, did you sync Sysvol and idmap.ldb from the existing DC ?
Shouldn't that be done naturally when DC joined the domain/when roles were
claimed? Sysvol is nearly empty though. I did not go far enough to create any
custom rules for this domain. Yet.
Also, why this is not mentioned on the wiki?
--
With best regards,
Andrey Repin
Thursday, June 8, 2023 23:54:38
Sorry for my terrible english...
More information about the samba
mailing list