Hello, I needed to replace an old Samba AD PDC with a new one, so I've installed the new one (Ubuntu 20.04 + Samba 4.15.13 from Ubuntu repository), joined it to the AD domain, demoted the primary, then removed it. All steps have been done following the Samba official howtos: https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory and https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC and every one after having tested the previous one's success. Afterwards, to avoid needing to change all DNS and printers settings on the clients, I've added the old PDC's IP and name to the new PDC. Samba's DNS is now correctly answering on both IPs, while share access from Windows clients always fails for wrong credentials. From a linux client with smbclient instead the shares are accessible. When a Windows client tries to connect to a share with the old PDC name, eg. \\dc1.samdom.example.com\netlogon, these errors appears in its Samba log (sanitized: DC1 is the old server's name, DC2 the new one's): [2023/06/22 15:53:44.777523, 1] ../../source4/auth/gensec/gensec_gssapi.c:791(gensec_gssapi_update_internal) GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find DC2$@SAMDOM.EXAMPLE.COM(kvno 1) in keytab FILE:/var/lib/samba/private/secrets.keytab (aes256-cts-hmac-sha1-96) [2023/06/22 15:53:44.777912, 1] ../../auth/gensec/spnego.c:1242(gensec_spnego_server_negTokenInit_step) gensec_spnego_server_negTokenInit_step: gssapi_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE [2023/06/22 15:53:44.873716, 1] ../../source4/auth/gensec/gensec_gssapi.c:791(gensec_gssapi_update_internal) GSS server Update(krb5)(1) Update failed: Miscellaneous failure (see text): Failed to find DC2$@SAMDOM.EXAMPLE.COM(kvno 1) in keytab FILE:/var/lib/samba/private/secrets.keytab (aes256-cts-hmac-sha1-96) [2023/06/22 15:53:44.873815, 1] ../../auth/gensec/spnego.c:1242(gensec_spnego_server_negTokenInit_step) gensec_spnego_server_negTokenInit_step: gssapi_krb5: parsing NEG_TOKEN_INIT content failed (next[(null)]): NT_STATUS_LOGON_FAILURE I've read on this thread: https://lists.samba.org/archive/samba/2017-December/212597.html that i have to add both a cname with the old name to the DNS and a servicePrincipalName, but still no go. Maybe I've not added it correctly the SPN. What is the right way to do this? Or what else can I do to fix the issue? Thanks, Antonio Trogu
On 06/07/2023 16:16, Antonio Trogu via samba wrote:> Hello, > > I needed to replace an old Samba AD PDC with a new one, so I've > installed the new one (Ubuntu 20.04 + Samba 4.15.13 from Ubuntu > repository), joined it to the AD domain, demoted the primary, then > removed it.I got totally confused the first time that I read the above, I had to read it a few times before I fully understood it. The reason being, on first scan I thought that Antonio was trying to join an NT4-style PDC to an AD domain, which isn't the case. What he is trying to do is replace an AD DC that currently holds the PDC_Emulator FSMO role. There are no such terms as 'PDC' and 'primary' associated with AD, all DC's are equal (apart from the FSMO roles and they can be on any DC) Sorry if that sounds like preaching, but it is just the way (along with a lot of others) that I see it.> All steps have been done following the Samba official howtos: > > https://wiki.samba.org/index.php/Joining_a_Samba_DC_to_an_Existing_Active_Directory > > and > > https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC > > and every one after having tested the previous one's success. > > Afterwards, to avoid needing to change all DNS and printers settings on > the clients, I've added the old PDC's IP and name to the new PDC. > Samba's DNS is now correctly answering on both IPs, while share access > from Windows clients always fails for wrong credentials. From a linux > client with smbclient instead the shares are accessible.I hope that you are running more than one DC, if you are, I would have transferred all the FSMO roles to another DC, demoted the original DC, cleaned up its meta data in AD and then used the same name and ipaddress for the new DC, joined it to the domain and then transferred the FSMO roles back again. If you don't want to do that, you should use a CNAME. Rowland