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
Why do you have a netlogon share on the Unix domain member ?
Why are you using Wins ? AD does not use Wins, it uses DNS.
Why do you have this line: 'idmap config * : schema_mode = rfc2307'
Finally, you have the 'winbind enum' lines set to yes on both machines,
this should only be done for testing purposes, Samba will quite
correctly without the lines.
When you created your new DC, did you sync Sysvol and idmap.ldb from the
existing DC ?
Rowland