Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Today's episode of "why is AD break", brought to you by:

> [2017/09/05 10:17:06.015617,  3] ../source4/auth/gensec/gensec_gssapi.c:613(gensec_gssapi_update)
>   Server GC/graz-dc-1b.ad.tao.at/ad.tao.at is not registered with our KDC:  Miscellaneous failure (see text): Server (GC/graz-dc-1b.ad.tao.at/[hidden email]) unknown
> [2017/09/05 10:17:06.015717,  0] ../source4/librpc/rpc/dcerpc_util.c:745(dcerpc_pipe_auth_recv)
>   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for ncacn_ip_tcp:192.168.17.66[1024,seal,krb5,target_hostname=bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at,target_principal=GC/graz-dc-1b.ad.tao.at/ad.tao.at,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc2dcd2/0x00000004,localaddress=192.168.16.213] NT_STATUS_INVALID_PARAMETER
> [2017/09/05 10:17:06.015869,  4] ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
>   dreplsrv_notify: Failed to send DsReplicaSync to bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at for DC=ad,DC=tao,DC=at - NT_STATUS_INVALID_PARAMETER : WERR_INVALID_PARAM

The few google results for this seem to indicate DNS issues, but I'm not
sure where those should come from. The servers in question resolve
graz-dc-1b.ad.tao.at as well as
bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at to the correct IP.
Same goes for _kerberos.* and the other SRV records in _msdcs. and the
AD domain itself.

Any ideas where else to look?

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Ah.. I had a "member break down" ..  

Out of the blue,.. Kerberos problem, but pretty simple to fix.

kinit Administrator
Check your spn of the ad server with :  
samba-tool spn list DC_HOSTNAME$

Check keytab
klist -ke /var/lib/samba/private/secrets.keytab

Can you check this.

Greetz,

Louis


> -----Oorspronkelijk bericht-----
> Van: samba [mailto:[hidden email]] Namens Sven
> Schwedas via samba
> Verzonden: dinsdag 5 september 2017 14:28
> Aan: [hidden email]
> Onderwerp: [Samba] Server GC/name.dom/dom is not registered
> with our KDC: Miscellaneous failure (see text): Server
> (GC/name/dom@DOM) unknown
>
> Today's episode of "why is AD break", brought to you by:
>
> > [2017/09/05 10:17:06.015617,  3]
> ../source4/auth/gensec/gensec_gssapi.c:613(gensec_gssapi_update)
> >   Server GC/graz-dc-1b.ad.tao.at/ad.tao.at is not
> registered with our
> > KDC:  Miscellaneous failure (see text): Server
> > (GC/graz-dc-1b.ad.tao.at/[hidden email]) unknown
> > [2017/09/05 10:17:06.015717,  0]
> ../source4/librpc/rpc/dcerpc_util.c:745(dcerpc_pipe_auth_recv)
> >   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
> >
> ncacn_ip_tcp:192.168.17.66[1024,seal,krb5,target_hostname=bcffbad8-1ad
> >
> d-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at,target_principal=GC/graz-dc-
> >
> 1b.ad.tao.at/ad.tao.at,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc
> > 2dcd2/0x00000004,localaddress=192.168.16.213]
> > NT_STATUS_INVALID_PARAMETER
> > [2017/09/05 10:17:06.015869,  4]
> ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
> >   dreplsrv_notify: Failed to send DsReplicaSync to
> > bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at for
> > DC=ad,DC=tao,DC=at - NT_STATUS_INVALID_PARAMETER :
> WERR_INVALID_PARAM
>
> The few google results for this seem to indicate DNS issues,
> but I'm not sure where those should come from. The servers in
> question resolve graz-dc-1b.ad.tao.at as well as
> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at to the
> correct IP.
> Same goes for _kerberos.* and the other SRV records in
> _msdcs. and the AD domain itself.
>
> Any ideas where else to look?
>
> --
> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
> Systemadministrator Mail/XMPP [hidden email] | Skype
> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
> https://www.tao-digital.at | Tel +43 680 301 7167
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-05 14:40, L.P.H. van Belle wrote:
> Ah.. I had a "member break down" ..  
>
> Out of the blue,.. Kerberos problem, but pretty simple to fix.
>
> kinit Administrator

Works on all DCs.

> Check your spn of the ad server with :  
> samba-tool spn list DC_HOSTNAME$
>
> Check keytab
> klist -ke /var/lib/samba/private/secrets.keytab

Outputs attached. graz-dc-1b is the one making trouble, graz-dc-sem is
the FSMO role holder.

Keytabs look reasonable, as far as I can see, but why does graz-dc-sem
have the same SPN output as graz-dc-1b in addition to its own?

> Can you check this.
>
> Greetz,
>
> Louis
>
>
>> -----Oorspronkelijk bericht-----
>> Van: samba [mailto:[hidden email]] Namens Sven
>> Schwedas via samba
>> Verzonden: dinsdag 5 september 2017 14:28
>> Aan: [hidden email]
>> Onderwerp: [Samba] Server GC/name.dom/dom is not registered
>> with our KDC: Miscellaneous failure (see text): Server
>> (GC/name/dom@DOM) unknown
>>
>> Today's episode of "why is AD break", brought to you by:
>>
>>> [2017/09/05 10:17:06.015617,  3]
>> ../source4/auth/gensec/gensec_gssapi.c:613(gensec_gssapi_update)
>>>   Server GC/graz-dc-1b.ad.tao.at/ad.tao.at is not
>> registered with our
>>> KDC:  Miscellaneous failure (see text): Server
>>> (GC/graz-dc-1b.ad.tao.at/[hidden email]) unknown
>>> [2017/09/05 10:17:06.015717,  0]
>> ../source4/librpc/rpc/dcerpc_util.c:745(dcerpc_pipe_auth_recv)
>>>   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
>>>
>> ncacn_ip_tcp:192.168.17.66[1024,seal,krb5,target_hostname=bcffbad8-1ad
>>>
>> d-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at,target_principal=GC/graz-dc-
>>>
>> 1b.ad.tao.at/ad.tao.at,abstract_syntax=e3514235-4b06-11d1-ab04-00c04fc
>>> 2dcd2/0x00000004,localaddress=192.168.16.213]
>>> NT_STATUS_INVALID_PARAMETER
>>> [2017/09/05 10:17:06.015869,  4]
>> ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
>>>   dreplsrv_notify: Failed to send DsReplicaSync to
>>> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at for
>>> DC=ad,DC=tao,DC=at - NT_STATUS_INVALID_PARAMETER :
>> WERR_INVALID_PARAM
>>
>> The few google results for this seem to indicate DNS issues,
>> but I'm not sure where those should come from. The servers in
>> question resolve graz-dc-1b.ad.tao.at as well as
>> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at to the
>> correct IP.
>> Same goes for _kerberos.* and the other SRV records in
>> _msdcs. and the AD domain itself.
>>
>> Any ideas where else to look?
>>
>> --
>> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
>> Systemadministrator Mail/XMPP [hidden email] | Skype
>> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
>> https://www.tao-digital.at | Tel +43 680 301 7167
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>
--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   2 HOST/[hidden email] (des-cbc-crc)
   2 HOST/[hidden email] (des-cbc-crc)
   2 GRAZ-DC-1B$@AD.TAO.AT (des-cbc-crc)
   2 HOST/[hidden email] (des-cbc-md5)
   2 HOST/[hidden email] (des-cbc-md5)
   2 GRAZ-DC-1B$@AD.TAO.AT (des-cbc-md5)
   2 HOST/[hidden email] (arcfour-hmac)
   2 HOST/[hidden email] (arcfour-hmac)
   2 GRAZ-DC-1B$@AD.TAO.AT (arcfour-hmac)
   2 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   2 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   2 GRAZ-DC-1B$@AD.TAO.AT (aes128-cts-hmac-sha1-96)
   2 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   2 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   2 GRAZ-DC-1B$@AD.TAO.AT (aes256-cts-hmac-sha1-96)

graz-dc-1b$
User CN=GRAZ-DC-1B,OU=Domain Controllers,DC=ad,DC=tao,DC=at has the following servicePrincipalName:
         HOST/GRAZ-DC-1B
         HOST/graz-dc-1b.ad.tao.at
         GC/graz-dc-1b.ad.tao.at/ad.tao.at
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/bcffbad8-1add-46b9-bf69-90e52c0f09ea/ad.tao.at
         HOST/graz-dc-1b.ad.tao.at/AD
         ldap/graz-dc-1b.ad.tao.at/AD
         ldap/graz-dc-1b.ad.tao.at
         HOST/graz-dc-1b.ad.tao.at/ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/ad.tao.at
         ldap/bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at
         ldap/GRAZ-DC-1B
         RestrictedKrbHost/GRAZ-DC-1B
         RestrictedKrbHost/graz-dc-1b.ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/DomainDnsZones.ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/ForestDnsZones.ad.tao.at

Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HOST/[hidden email] (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-crc)
   1 GRAZ-DC-SEM$@AD.TAO.AT (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-md5)
   1 HOST/[hidden email] (des-cbc-md5)
   1 GRAZ-DC-SEM$@AD.TAO.AT (des-cbc-md5)
   1 HOST/[hidden email] (arcfour-hmac)
   1 HOST/[hidden email] (arcfour-hmac)
   1 GRAZ-DC-SEM$@AD.TAO.AT (arcfour-hmac)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 GRAZ-DC-SEM$@AD.TAO.AT (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 GRAZ-DC-SEM$@AD.TAO.AT (aes256-cts-hmac-sha1-96)

graz-dc-sem$
User CN=GRAZ-DC-SEM,OU=Domain Controllers,DC=ad,DC=tao,DC=at has the following servicePrincipalName:
         HOST/graz-dc-sem.ad.tao.at
         HOST/graz-dc-sem.ad.tao.at/AD
         ldap/graz-dc-sem.ad.tao.at/AD
         GC/graz-dc-sem.ad.tao.at/ad.tao.at
         ldap/graz-dc-sem.ad.tao.at
         HOST/graz-dc-sem.ad.tao.at/ad.tao.at
         ldap/graz-dc-sem.ad.tao.at/ad.tao.at
         HOST/GRAZ-DC-SEM
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/160f5a53-5c29-4a83-aeee-6cb1dbabeed7/ad.tao.at
         ldap/160f5a53-5c29-4a83-aeee-6cb1dbabeed7._msdcs.ad.tao.at
         ldap/GRAZ-DC-SEM
         RestrictedKrbHost/GRAZ-DC-SEM
         RestrictedKrbHost/graz-dc-sem.ad.tao.at
         ldap/graz-dc-sem.ad.tao.at/DomainDnsZones.ad.tao.at
         ldap/graz-dc-sem.ad.tao.at/ForestDnsZones.ad.tao.at
         HOST/graz-dc-1b.ad.tao.at
         HOST/graz-dc-1b.ad.tao.at/AD
         ldap/graz-dc-1b.ad.tao.at/AD
         GC/graz-dc-1b.ad.tao.at/ad.tao.at
         ldap/graz-dc-1b.ad.tao.at
         HOST/graz-dc-1b.ad.tao.at/ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/ad.tao.at
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/bcffbad8-1add-46b9-bf69-90e52c0f09ea/ad.tao.at
         ldap/bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at
         RestrictedKrbHost/graz-dc-1b.ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/DomainDnsZones.ad.tao.at
         ldap/graz-dc-1b.ad.tao.at/ForestDnsZones.ad.tao.at

Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HOST/[hidden email] (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-crc)
   1 VILLACH-DC-BIS$@AD.TAO.AT (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-md5)
   1 HOST/[hidden email] (des-cbc-md5)
   1 VILLACH-DC-BIS$@AD.TAO.AT (des-cbc-md5)
   1 HOST/[hidden email] (arcfour-hmac)
   1 HOST/[hidden email] (arcfour-hmac)
   1 VILLACH-DC-BIS$@AD.TAO.AT (arcfour-hmac)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 VILLACH-DC-BIS$@AD.TAO.AT (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 VILLACH-DC-BIS$@AD.TAO.AT (aes256-cts-hmac-sha1-96)

villach-dc-bis$
User CN=VILLACH-DC-BIS,OU=Domain Controllers,DC=ad,DC=tao,DC=at has the following servicePrincipalName:
         HOST/VILLACH-DC-BIS
         HOST/VILLACH-DC-BIS.ad.tao.at
         GC/VILLACH-DC-BIS.ad.tao.at/ad.tao.at
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/e1569c90-50f9-4bb5-bd85-79145e3ff6fd/ad.tao.at
         HOST/VILLACH-DC-BIS.ad.tao.at/AD
         ldap/VILLACH-DC-BIS.ad.tao.at/AD
         ldap/VILLACH-DC-BIS.ad.tao.at
         HOST/VILLACH-DC-BIS.ad.tao.at/ad.tao.at
         ldap/VILLACH-DC-BIS.ad.tao.at/ad.tao.at
         ldap/e1569c90-50f9-4bb5-bd85-79145e3ff6fd._msdcs.ad.tao.at
         ldap/VILLACH-DC-BIS
         RestrictedKrbHost/VILLACH-DC-BIS
         RestrictedKrbHost/VILLACH-DC-BIS.ad.tao.at
         ldap/VILLACH-DC-BIS.ad.tao.at/DomainDnsZones.ad.tao.at
         ldap/VILLACH-DC-BIS.ad.tao.at/ForestDnsZones.ad.tao.at

Keytab name: FILE:/var/lib/samba/private/secrets.keytab
KVNO Principal
---- --------------------------------------------------------------------------
   1 HOST/[hidden email] (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-crc)
   1 VILLACH-DC-SEM$@AD.TAO.AT (des-cbc-crc)
   1 HOST/[hidden email] (des-cbc-md5)
   1 HOST/[hidden email] (des-cbc-md5)
   1 VILLACH-DC-SEM$@AD.TAO.AT (des-cbc-md5)
   1 HOST/[hidden email] (arcfour-hmac)
   1 HOST/[hidden email] (arcfour-hmac)
   1 VILLACH-DC-SEM$@AD.TAO.AT (arcfour-hmac)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes128-cts-hmac-sha1-96)
   1 VILLACH-DC-SEM$@AD.TAO.AT (aes128-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 HOST/[hidden email] (aes256-cts-hmac-sha1-96)
   1 VILLACH-DC-SEM$@AD.TAO.AT (aes256-cts-hmac-sha1-96)

villach-dc-sem$
User CN=VILLACH-DC-SEM,OU=Domain Controllers,DC=ad,DC=tao,DC=at has the following servicePrincipalName:
         HOST/VILLACH-DC-SEM
         HOST/VILLACH-DC-SEM.ad.tao.at
         GC/VILLACH-DC-SEM.ad.tao.at/ad.tao.at
         E3514235-4B06-11D1-AB04-00C04FC2DCD2/eb5f9772-cd8f-4cde-9629-f1898c94aedd/ad.tao.at
         HOST/VILLACH-DC-SEM.ad.tao.at/AD
         ldap/VILLACH-DC-SEM.ad.tao.at/AD
         ldap/VILLACH-DC-SEM.ad.tao.at
         HOST/VILLACH-DC-SEM.ad.tao.at/ad.tao.at
         ldap/VILLACH-DC-SEM.ad.tao.at/ad.tao.at
         ldap/eb5f9772-cd8f-4cde-9629-f1898c94aedd._msdcs.ad.tao.at
         ldap/VILLACH-DC-SEM
         RestrictedKrbHost/VILLACH-DC-SEM
         RestrictedKrbHost/VILLACH-DC-SEM.ad.tao.at
         ldap/VILLACH-DC-SEM.ad.tao.at/DomainDnsZones.ad.tao.at
         ldap/VILLACH-DC-SEM.ad.tao.at/ForestDnsZones.ad.tao.at

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
> Keytabs look reasonable, as far as I can see, but why does
> graz-dc-sem have the same SPN output as graz-dc-1b in
> addition to its own?
A snapshotted server/cloned server? I dont know but thats not correct.

I suggest, cleanup the DS with FSMO roles.
Then remove a failty server and re-add it as a new installed DC.

( the good DS with FSMO)
First backup: /var/lib/samba/private/secrets.keytab
Remove the incorrect entries from keytab file with ktutil
rkt /var/lib/samba/private/secrets.keytab
list -e -t

Check if dates here are related to other work you/someone did?

Now you can remove the failty one from the domain and re-add it (with provisioning)
Backup and cleanup
/etc/samba/smb.conf  (rename)
/var/cache/samba   ( remove all files from folder)
/var/lib/samba   ( remove all files and directories from folder)

Now re-provision and you should have correct working DC's again.

! Before re-provisioning, make sure all OLD records dns and AD are gone.



Greetz,

Louis

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:[hidden email]]
> Verzonden: dinsdag 5 september 2017 15:34
> Aan: L.P.H. van Belle; [hidden email]
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
>
> On 2017-09-05 14:40, L.P.H. van Belle wrote:
> > Ah.. I had a "member break down" ..  
> >
> > Out of the blue,.. Kerberos problem, but pretty simple to fix.
> >
> > kinit Administrator
>
> Works on all DCs.
>
> > Check your spn of the ad server with :  
> > samba-tool spn list DC_HOSTNAME$
> >
> > Check keytab
> > klist -ke /var/lib/samba/private/secrets.keytab
>
> Outputs attached. graz-dc-1b is the one making trouble,
> graz-dc-sem is the FSMO role holder.
>
> Keytabs look reasonable, as far as I can see, but why does
> graz-dc-sem have the same SPN output as graz-dc-1b in
> addition to its own?
>
> > Can you check this.
> >
> > Greetz,
> >
> > Louis
> >
> >
> >> -----Oorspronkelijk bericht-----
> >> Van: samba [mailto:[hidden email]] Namens Sven
> >> Schwedas via samba
> >> Verzonden: dinsdag 5 september 2017 14:28
> >> Aan: [hidden email]
> >> Onderwerp: [Samba] Server GC/name.dom/dom is not
> registered with our
> >> KDC: Miscellaneous failure (see text): Server
> >> (GC/name/dom@DOM) unknown
> >>
> >> Today's episode of "why is AD break", brought to you by:
> >>
> >>> [2017/09/05 10:17:06.015617,  3]
> >> ../source4/auth/gensec/gensec_gssapi.c:613(gensec_gssapi_update)
> >>>   Server GC/graz-dc-1b.ad.tao.at/ad.tao.at is not
> >> registered with our
> >>> KDC:  Miscellaneous failure (see text): Server
> >>> (GC/graz-dc-1b.ad.tao.at/[hidden email]) unknown
> >>> [2017/09/05 10:17:06.015717,  0]
> >> ../source4/librpc/rpc/dcerpc_util.c:745(dcerpc_pipe_auth_recv)
> >>>   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
> >>>
> >>
> ncacn_ip_tcp:192.168.17.66[1024,seal,krb5,target_hostname=bcffbad8-1a
> >> d
> >>>
> >>
> d-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at,target_principal=GC/graz-dc
> >> -
> >>>
> >>
> 1b.ad.tao.at/ad.tao.at,abstract_syntax=e3514235-4b06-11d1-ab04-00c04f
> >> c
> >>> 2dcd2/0x00000004,localaddress=192.168.16.213]
> >>> NT_STATUS_INVALID_PARAMETER
> >>> [2017/09/05 10:17:06.015869,  4]
> >>
> ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
> >>>   dreplsrv_notify: Failed to send DsReplicaSync to
> >>> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at for
> >>> DC=ad,DC=tao,DC=at - NT_STATUS_INVALID_PARAMETER :
> >> WERR_INVALID_PARAM
> >>
> >> The few google results for this seem to indicate DNS
> issues, but I'm
> >> not sure where those should come from. The servers in question
> >> resolve graz-dc-1b.ad.tao.at as well as
> >> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at to
> the correct
> >> IP.
> >> Same goes for _kerberos.* and the other SRV records in _msdcs. and
> >> the AD domain itself.
> >>
> >> Any ideas where else to look?
> >>
> >> --
> >> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
> >> Systemadministrator Mail/XMPP [hidden email] | Skype
> >> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
> >> https://www.tao-digital.at | Tel +43 680 301 7167
> >>
> >> --
> >> To unsubscribe from this list go to the following URL and read the
> >> instructions:  https://lists.samba.org/mailman/options/samba
> >>
> >
>
> --
> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
> Systemadministrator Mail/XMPP [hidden email] | Skype
> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
> https://www.tao-digital.at | Tel +43 680 301 7167
>


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-05 16:21, L.P.H. van Belle wrote:
>> Keytabs look reasonable, as far as I can see, but why does
>> graz-dc-sem have the same SPN output as graz-dc-1b in
>> addition to its own?
> A snapshotted server/cloned server? I dont know but thats not correct.

Nope, both were created clean. There used to be a graz-dc-bis, but
removing and re-adding it completely broke replication, so I nuked it
and created 1b to replace it. That odyssey is in the list archives
somewhere…

> I suggest, cleanup the DS with FSMO roles.

Clean up as in move FSMO roles to a clean server (leaves only
villach-dc-*) ?

> Then remove a failty server and re-add it as a new installed DC.
> ( the good DS with FSMO)
> First backup: /var/lib/samba/private/secrets.keytab
> Remove the incorrect entries from keytab file with ktutil
> rkt /var/lib/samba/private/secrets.keytab
> list -e -t

Might as well just nuke graz-dc-sem and add a complete new DC from
scratch, no?

> Check if dates here are related to other work you/someone did?
>
> Now you can remove the failty one from the domain and re-add it (with provisioning)
> Backup and cleanup
> /etc/samba/smb.conf  (rename)
> /var/cache/samba   ( remove all files from folder)
> /var/lib/samba   ( remove all files and directories from folder)
>
> Now re-provision and you should have correct working DC's again.
>
> ! Before re-provisioning, make sure all OLD records dns and AD are gone.

I still have undeleteable replication records from the last time I had
to nuke a DC, nobody replied to my emails on that issue.

>
>
>
> Greetz,
>
> Louis
>
>> -----Oorspronkelijk bericht-----
>> Van: Sven Schwedas [mailto:[hidden email]]
>> Verzonden: dinsdag 5 september 2017 15:34
>> Aan: L.P.H. van Belle; [hidden email]
>> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
>> registered with our KDC: Miscellaneous failure (see text):
>> Server (GC/name/dom@DOM) unknown
>>
>> On 2017-09-05 14:40, L.P.H. van Belle wrote:
>>> Ah.. I had a "member break down" ..  
>>>
>>> Out of the blue,.. Kerberos problem, but pretty simple to fix.
>>>
>>> kinit Administrator
>>
>> Works on all DCs.
>>
>>> Check your spn of the ad server with :  
>>> samba-tool spn list DC_HOSTNAME$
>>>
>>> Check keytab
>>> klist -ke /var/lib/samba/private/secrets.keytab
>>
>> Outputs attached. graz-dc-1b is the one making trouble,
>> graz-dc-sem is the FSMO role holder.
>>
>> Keytabs look reasonable, as far as I can see, but why does
>> graz-dc-sem have the same SPN output as graz-dc-1b in
>> addition to its own?
>>
>>> Can you check this.
>>>
>>> Greetz,
>>>
>>> Louis
>>>
>>>
>>>> -----Oorspronkelijk bericht-----
>>>> Van: samba [mailto:[hidden email]] Namens Sven
>>>> Schwedas via samba
>>>> Verzonden: dinsdag 5 september 2017 14:28
>>>> Aan: [hidden email]
>>>> Onderwerp: [Samba] Server GC/name.dom/dom is not
>> registered with our
>>>> KDC: Miscellaneous failure (see text): Server
>>>> (GC/name/dom@DOM) unknown
>>>>
>>>> Today's episode of "why is AD break", brought to you by:
>>>>
>>>>> [2017/09/05 10:17:06.015617,  3]
>>>> ../source4/auth/gensec/gensec_gssapi.c:613(gensec_gssapi_update)
>>>>>   Server GC/graz-dc-1b.ad.tao.at/ad.tao.at is not
>>>> registered with our
>>>>> KDC:  Miscellaneous failure (see text): Server
>>>>> (GC/graz-dc-1b.ad.tao.at/[hidden email]) unknown
>>>>> [2017/09/05 10:17:06.015717,  0]
>>>> ../source4/librpc/rpc/dcerpc_util.c:745(dcerpc_pipe_auth_recv)
>>>>>   Failed to bind to uuid e3514235-4b06-11d1-ab04-00c04fc2dcd2 for
>>>>>
>>>>
>> ncacn_ip_tcp:192.168.17.66[1024,seal,krb5,target_hostname=bcffbad8-1a
>>>> d
>>>>>
>>>>
>> d-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at,target_principal=GC/graz-dc
>>>> -
>>>>>
>>>>
>> 1b.ad.tao.at/ad.tao.at,abstract_syntax=e3514235-4b06-11d1-ab04-00c04f
>>>> c
>>>>> 2dcd2/0x00000004,localaddress=192.168.16.213]
>>>>> NT_STATUS_INVALID_PARAMETER
>>>>> [2017/09/05 10:17:06.015869,  4]
>>>>
>> ../source4/dsdb/repl/drepl_notify.c:196(dreplsrv_notify_op_callback)
>>>>>   dreplsrv_notify: Failed to send DsReplicaSync to
>>>>> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at for
>>>>> DC=ad,DC=tao,DC=at - NT_STATUS_INVALID_PARAMETER :
>>>> WERR_INVALID_PARAM
>>>>
>>>> The few google results for this seem to indicate DNS
>> issues, but I'm
>>>> not sure where those should come from. The servers in question
>>>> resolve graz-dc-1b.ad.tao.at as well as
>>>> bcffbad8-1add-46b9-bf69-90e52c0f09ea._msdcs.ad.tao.at to
>> the correct
>>>> IP.
>>>> Same goes for _kerberos.* and the other SRV records in _msdcs. and
>>>> the AD domain itself.
>>>>
>>>> Any ideas where else to look?
>>>>
>>>> --
>>>> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
>>>> Systemadministrator Mail/XMPP [hidden email] | Skype
>>>> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
>>>> https://www.tao-digital.at | Tel +43 680 301 7167
>>>>
>>>> --
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions:  https://lists.samba.org/mailman/options/samba
>>>>
>>>
>>
>> --
>> Mit freundlichen Grüßen, / Best Regards, Sven Schwedas,
>> Systemadministrator Mail/XMPP [hidden email] | Skype
>> sven.schwedas TAO Digital | Lendplatz 45 | A8020 Graz
>> https://www.tao-digital.at | Tel +43 680 301 7167
>>
>

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Yes, if you flexible with reinstalling, you could..
(more below)

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:[hidden email]]
> Verzonden: dinsdag 5 september 2017 16:32
> Aan: L.P.H. van Belle; [hidden email]
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
>
> On 2017-09-05 16:21, L.P.H. van Belle wrote:
> >> Keytabs look reasonable, as far as I can see, but why does
> >> graz-dc-sem have the same SPN output as graz-dc-1b in
> addition to its
> >> own?
> > A snapshotted server/cloned server? I dont know but thats
> not correct.
>
> Nope, both were created clean. There used to be a
> graz-dc-bis, but removing and re-adding it completely broke
> replication, so I nuked it and created 1b to replace it. That
> odyssey is in the list archives somewhere…

Very strange then if they where all created clean.
removing and re-adding is possible, but not without rist.

>
> > I suggest, cleanup the DS with FSMO roles.
>
> Clean up as in move FSMO roles to a clean server (leaves only
> villach-dc-*) ?
Yes and no.  ;-)

I suggest the following, move fsmo roles to villach-dc and check database replications.

Remove the most faulty one first, graz-dc-1b, from the domain. ( check and cleanup DNS and AD! Very important )

You dont have to reinstall the complete os, just cleanup as told, and reprovisioning that server again.
Reboot and then wait, and check database replication again.
! Do reboot !

And repeat for all servers you dont trust.

That should bring you network back as it should be.


>
> > Then remove a failty server and re-add it as a new installed DC.
> > ( the good DS with FSMO)
> > First backup: /var/lib/samba/private/secrets.keytab
> > Remove the incorrect entries from keytab file with ktutil rkt
> > /var/lib/samba/private/secrets.keytab
> > list -e -t
>
> Might as well just nuke graz-dc-sem and add a complete new DC
> from scratch, no?
No, and yes, but i preffer no, not needed (yet).
Start with the keytab cleanup
Check the dns record if the uuid A PTR and hostnames resolve to the correct server.
If thats the case, then no, cleanup of keytab is, i think, sufficient.

Yes, if its really a mess. ;-)
Then, first a an new DC, then remove, just make sure you always have 2 dc's up and running (correctly)


>
> > Check if dates here are related to other work you/someone did?
> >
> > Now you can remove the failty one from the domain and
> re-add it (with
> > provisioning) Backup and cleanup /etc/samba/smb.conf  (rename)
> > /var/cache/samba   ( remove all files from folder)
> > /var/lib/samba   ( remove all files and directories
> from folder)
> >
> > Now re-provision and you should have correct working DC's again.
> >
> > ! Before re-provisioning, make sure all OLD records dns and
> AD are gone.
>
> I still have undeleteable replication records from the last
> time I had to nuke a DC, nobody replied to my emails on that issue.

Ok, now, im out of office in about 10 min, but mail that subject for me again.
I'll have a look.
Own and if you dont use it, ApacheDirectoryStudio can help a lot with cleanup of these kind of things.
But just make sure you know what you delete, for you mess up the AD even more.


Greetz,

Louis


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-05 16:52, L.P.H. van Belle wrote:
> Yes, if you flexible with reinstalling, you could..

I don't want another quick and dirty solution that turns out to break
half a year down the line, I'm fine with nuking half my DCs if that
means getting to a clean state.

Besides, recreating containers is faster than manually messing around in
/var/lib on each one of them.

> I suggest the following, move fsmo roles to villach-dc and check database replications.

DB replication is already spewing errors, what am I to look out for?

> Remove the most faulty one first, graz-dc-1b, from the domain. ( check and cleanup DNS and AD! Very important )

What to check for? What to clean up?

> You dont have to reinstall the complete os, just cleanup as told, and reprovisioning that server again.

Adding a new DC with the same hostname as the old DC is what got me into
trouble last time. I'll pass up on that offer.

>>> Then remove a failty server and re-add it as a new installed DC.
>>> ( the good DS with FSMO)
>>> First backup: /var/lib/samba/private/secrets.keytab
>>> Remove the incorrect entries from keytab file with ktutil rkt
>>> /var/lib/samba/private/secrets.keytab
>>> list -e -t
>>
>> Might as well just nuke graz-dc-sem and add a complete new DC
>> from scratch, no?
> No, and yes, but i preffer no, not needed (yet).
> Start with the keytab cleanup
> Check the dns record if the uuid A PTR and hostnames resolve to the correct server.
> If thats the case, then no, cleanup of keytab is, i think, sufficient.

Just to confirm the order: Clean up the keytab, if that doesn't work,
start removing servers?

> Yes, if its really a mess. ;-)
> Then, first a an new DC, then remove, just make sure you always have 2 dc's up and running (correctly)

Servers in Villach seem to run fine, thank $DEITY, so I'll leave them
alone for now.

>>> Now re-provision and you should have correct working DC's again.
>>>
>>> ! Before re-provisioning, make sure all OLD records dns and
>> AD are gone.
>>
>> I still have undeleteable replication records from the last
>> time I had to nuke a DC, nobody replied to my emails on that issue.
>
> Ok, now, im out of office in about 10 min, but mail that subject for me again> I'll have a look.

First message on that topic:
https://lists.samba.org/archive/samba/2017-March/207429.html

Last message, where I mentioned the replication bug:
https://lists.samba.org/archive/samba/2017-April/207918.html

> Own and if you dont use it, ApacheDirectoryStudio can help a lot with cleanup of these kind of things.

Currently I'm using the ADSI MMC snap-in, any downsides compared to ADS?

> But just make sure you know what you delete, for you mess up the AD even more.

That why I'm not touching anything without a full list.

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Hai Sven,  

> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:[hidden email]]
> Verzonden: dinsdag 5 september 2017 17:13
> Aan: L.P.H. van Belle
> CC: [hidden email]
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
>
> On 2017-09-05 16:52, L.P.H. van Belle wrote:
> > Yes, if you flexible with reinstalling, you could..
>
> I don't want another quick and dirty solution that turns out
> to break half a year down the line, I'm fine with nuking half
> my DCs if that means getting to a clean state.
No,  i dont want a quick and dirty solution for you. You need to get a good fix.

>
> Besides, recreating containers is faster than manually
> messing around in /var/lib on each one of them.
>
> > I suggest the following, move fsmo roles to villach-dc and
> check database replications.
>
> DB replication is already spewing errors, what am I to look out for?
Ok, get my check db script, run it from any dc. And post me the output.
https://github.com/thctlo/samba4/blob/master/samba-check-db-repl.sh 
With the output, we should be able to see which servers have the best replicated database.
( the script uses the standaard samba tools, but all in one go)

>
> > Remove the most faulty one first, graz-dc-1b, from the
> domain. ( check
> > and cleanup DNS and AD! Very important )
>
> What to check for? What to clean up?
Ah, thats hard to tell, this depends a bit on the errors.
I search/look for the left overs, first with RSAT tools and samba-tool, then with ApacheStudio.
I look for hostnames/UUID/ things like that, but this is only done if all other options did not work.
But it depends on the errors/warnings i see/get.

>
> > You dont have to reinstall the complete os, just cleanup as
> told, and reprovisioning that server again.
>
> Adding a new DC with the same hostname as the old DC is what
> got me into trouble last time. I'll pass up on that offer.
Ok, but i know the correct steps to do this, its all in the correct order and when to remove where/what.
I can save you the time to reinstall the OS, you can re-use the os, just dont reuse the same hostname.
But, if its not an option for you anymore, thats ok, that what you want.

>
> >>> Then remove a failty server and re-add it as a new installed DC.
> >>> ( the good DS with FSMO)
> >>> First backup: /var/lib/samba/private/secrets.keytab
> >>> Remove the incorrect entries from keytab file with ktutil rkt
> >>> /var/lib/samba/private/secrets.keytab
> >>> list -e -t
> >>
> >> Might as well just nuke graz-dc-sem and add a complete new DC from
> >> scratch, no?
> > No, and yes, but i preffer no, not needed (yet).
> > Start with the keytab cleanup
> > Check the dns record if the uuid A PTR and hostnames
> resolve to the correct server.
> > If thats the case, then no, cleanup of keytab is, i think,
> sufficient.
>
> Just to confirm the order: Clean up the keytab, if that
> doesn't work, start removing servers?
Almost. Backup then ...   Cleanup keytab of the server.

>
> > Yes, if its really a mess. ;-)
> > Then, first a an new DC, then remove, just make sure you
> always have 2
> > dc's up and running (correctly)
>
> Servers in Villach seem to run fine, thank $DEITY, so I'll
> leave them alone for now.
Ok, thats good, run the check-db script and post the complete output for me.

>
> >>> Now re-provision and you should have correct working DC's again.
> >>>
> >>> ! Before re-provisioning, make sure all OLD records dns and
> >> AD are gone.
> >>
> >> I still have undeleteable replication records from the last time I
> >> had to nuke a DC, nobody replied to my emails on that issue.
> >
> > Ok, now, im out of office in about 10 min, but mail that
> subject for me again> I'll have a look.
>
> First message on that topic:
> https://lists.samba.org/archive/samba/2017-March/207429.html
Ok, this one, track down both uuid's, checkout which which hostname belongs with these.
Basicly https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC 
In based on the Demoteing wiki example.
I do the same steps as shown there. Now the last three pictures on the site shows where to look.
At the site and Service, go through very folder, and check if it is as it should be.

https://lists.samba.org/archive/samba/2017-March/207460.html
Between 2 and 3, there the problem starts
>>  – I noticed a typo in the server's `netbios name` setting, corrected it, and restarted the DC.
3. Yes, for the new hostname, the old hostname is as left over in the ADDC DB and/or DNS.

This name GRAZ-DC-BIS, and the name with the typo. The GUID for these is where to look info.

Step 6. ah the point of origin of you problems with of the current post?

7. dnsmasq? Ok, i just hope these are not running on the DC's.

> Last message, where I mentioned the replication bug:
> https://lists.samba.org/archive/samba/2017-April/207918.html
>
> > Own and if you dont use it, ApacheDirectoryStudio can help
> a lot with cleanup of these kind of things.
>
> Currently I'm using the ADSI MMC snap-in, any downsides
> compared to ADS?
I dont know, never used ADS :-/

Track done these : GUID's, the hostname's, ipnumbers A and PTR records
7e4973ba-4093-4523-a70f-7caa4845e34d
d613fa11-064b-4bcc-ab01-20264f870f47
(how, see Verifying and Creating the objectGUID Record  https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Record)
And as suggested, do this first through the RSAT tools or samba-tools, try removing them with these tools first.
(how https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC)
Open the Active Directory Users and Computers application and set it to advanced view.

Now, i think the last left overs can be removed with : Active Directory Sites and Services and DNS manager.
And now check them all, every folder, take your time.

Then when its done, i run samba-tool dbcheck again per server.
>
> > But just make sure you know what you delete, for you mess
> up the AD even more.
>
> That why I'm not touching anything without a full list.
Yes, good, im pro that, the more info we get the better we can help you.


Greetz,

Louis


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-06 09:28, L.P.H. van Belle wrote:
>>> I suggest the following, move fsmo roles to villach-dc and
>> check database replications.
>>
>> DB replication is already spewing errors, what am I to look out for?
> Ok, get my check db script, run it from any dc. And post me the output.

Output attached. Seems like all servers but graz-dc-sem have some stuff
wrong, just wonderful.

> https://github.com/thctlo/samba4/blob/master/samba-check-db-repl.sh 

Just FYI, something's wonky with the script. Bash trips up on CRLF line
endings (everywhere) and 0xC2 control characters (ll. 260-261) sprinkled
through the file. Had to clean that up before it actually ran without
syntax errors.

>>> Remove the most faulty one first, graz-dc-1b, from the
>> domain. ( check
>>> and cleanup DNS and AD! Very important )
>>
>> What to check for? What to clean up?
> Ah, thats hard to tell, this depends a bit on the errors.
> I search/look for the left overs, first with RSAT tools and samba-tool, then with ApacheStudio.
> I look for hostnames/UUID/ things like that, but this is only done if all other options did not work.
> But it depends on the errors/warnings i see/get.

None of the differences look like they could cause the replication
errors, looks more like they're just the results.

>>>>> Then remove a failty server and re-add it as a new installed DC.
>>>>> ( the good DS with FSMO)
>>>>> First backup: /var/lib/samba/private/secrets.keytab
>>>>> Remove the incorrect entries from keytab file with ktutil rkt
>>>>> /var/lib/samba/private/secrets.keytab
>>>>> list -e -t
>>>>
>>>> Might as well just nuke graz-dc-sem and add a complete new DC from
>>>> scratch, no?
>>> No, and yes, but i preffer no, not needed (yet).
>>> Start with the keytab cleanup
>>> Check the dns record if the uuid A PTR and hostnames
>> resolve to the correct server.
>>> If thats the case, then no, cleanup of keytab is, i think,
>> sufficient.
>>
>> Just to confirm the order: Clean up the keytab, if that
>> doesn't work, start removing servers?
> Almost. Backup then ...   Cleanup keytab of the server.
I'll try that next, unless you find something shady in the report.

>>> Yes, if its really a mess. ;-)
>>> Then, first a an new DC, then remove, just make sure you
>> always have 2
>>> dc's up and running (correctly)
>>
>> Servers in Villach seem to run fine, thank $DEITY, so I'll
>> leave them alone for now.
> Ok, thats good, run the check-db script and post the complete output for me.
>
>>
>>>>> Now re-provision and you should have correct working DC's again.
>>>>>
>>>>> ! Before re-provisioning, make sure all OLD records dns and
>>>> AD are gone.
>>>>
>>>> I still have undeleteable replication records from the last time I
>>>> had to nuke a DC, nobody replied to my emails on that issue.
>>>
>>> Ok, now, im out of office in about 10 min, but mail that
>> subject for me again> I'll have a look.
>>
>> First message on that topic:
>> https://lists.samba.org/archive/samba/2017-March/207429.html
> Ok, this one, track down both uuid's, checkout which which hostname belongs with these.
Going by the output of `samba-tool drs showrepl` and sam.ldb, the GUIDs
are as follows:

graz-dc-sem 160f5a53-5c29-4a83-aeee-6cb1dbabeed7
graz-dc-bis 7e4973ba-4093-4523-a70f-7caa4845e34d (not in sam.ldb)
graz-dc-1b bcffbad8-1add-46b9-bf69-90e52c0f09ea
villach-dc-sem eb5f9772-cd8f-4cde-9629-f1898c94aedd
villach-dc-bis e1569c90-50f9-4bb5-bd85-79145e3ff6fd

villach-sem/bis want to replicate to the dead and removed graz-dc-bis
for some reason, but don't have its GUID in their sam.ldb either.

> Basicly https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC 
> In based on the Demoteing wiki example.
> I do the same steps as shown there. Now the last three pictures on the site shows where to look.
> At the site and Service, go through very folder, and check if it is as it should be.

I already checked it back then, and double checked it now. ADUC, ADSS
and DNS are all three clean and contain no reference to either the old
server name or its GUID.

> https://lists.samba.org/archive/samba/2017-March/207460.html
> Between 2 and 3, there the problem starts
>>>  – I noticed a typo in the server's `netbios name` setting, corrected it, and restarted the DC.
> 3. Yes, for the new hostname, the old hostname is as left over in the ADDC DB and/or DNS.
>
> This name GRAZ-DC-BIS, and the name with the typo. The GUID for these is where to look info.

Yeah, but where?

> Step 6. ah the point of origin of you problems with of the current post?

Hell if I know, but might be.

> 7. dnsmasq? Ok, i just hope these are not running on the DC's.

It's running on the gateways to cache the DCs' responses and handle some
auxiliary stuff. ad.tao.at and all subdomains are transparently
forwarded to the DCs, no difference in responses for _msdsc etc. between
them and querying the DCs directly.

>> Last message, where I mentioned the replication bug:
>> https://lists.samba.org/archive/samba/2017-April/207918.html
>>
>>> Own and if you dont use it, ApacheDirectoryStudio can help
>> a lot with cleanup of these kind of things.
>>
>> Currently I'm using the ADSI MMC snap-in, any downsides
>> compared to ADS?
> I dont know, never used ADS :-/
>
> Track done these : GUID's, the hostname's, ipnumbers A and PTR records
> 7e4973ba-4093-4523-a70f-7caa4845e34d
> d613fa11-064b-4bcc-ab01-20264f870f47
> (how, see Verifying and Creating the objectGUID Record  https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Record)
Neither of the two return any results on any DC (or on the dnsmasq
servers), but the GUIDs for the 4 currently existing DCs work fine. This
matches the data from the RSAT tools.

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

No password for user AD\Administrator was set in this script!
Please enter the password for AD\Administrator :
Running with with console output
Checking the DC_With_FSMO (graz-dc-sem) with SAMBA DC: villach-dc-sem.ad.tao.at
villach-dc-bis.ad.tao.at
graz-dc-1b.ad.tao.at
Running : /usr/bin/samba-tool ldapcmp --filter='whenChanged' ldap://graz-dc-sem.ad.tao.at ldap://villach-dc-sem.ad.tao.at
Please wait.. this can take a while..
ERROR: Compare failed: -1

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

Comparing:
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes with different values:

    mailAlt

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS
Running : /usr/bin/samba-tool ldapcmp --filter='whenChanged' ldap://graz-dc-sem.ad.tao.at ldap://villach-dc-bis.ad.tao.at
Please wait.. this can take a while..
ERROR: Compare failed: -1

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

Comparing:
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes with different values:

    mailAlt

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-bis.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

Comparing:
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-bis.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes with different values:

    mailAlt

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS
Running : /usr/bin/samba-tool ldapcmp --filter='whenChanged' ldap://graz-dc-sem.ad.tao.at ldap://graz-dc-1b.ad.tao.at
Please wait.. this can take a while..
ERROR: Compare failed: -1

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

Comparing:
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-sem.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes with different values:

    mailAlt

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED1,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-bis.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

Comparing:
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED2,CN=Users,DC=ad,DC=tao,DC=at' [ldap://villach-dc-bis.ad.tao.at]
    Difference in attribute values:
        mailAlt =>
[…REDACTED, GOOD…]
[…REDACTED, OUTDATED…]
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes with different values:

    mailAlt

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS

* Comparing [DOMAIN] context...

* Objects to be compared: 392

Comparing:
'CN=REDACTED3,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED3,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Difference in attribute values:
        objectClass =>
['organizationalPerson', 'person', 'taoUser', 'top', 'user']
['organizationalPerson', 'person', 'top', 'ucsUser', 'user']
    FAILED

Comparing:
'CN=REDACTED4,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED4,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Difference in attribute values:
        lastLogonTimestamp =>
['SMALLVALUE']
['BIGVALUE']
    FAILED

Comparing:
'CN=Enterprise Admins,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=Enterprise Admins,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Attributes found only in ldap://graz-dc-sem.ad.tao.at:
        msSFU30NisDomain
        gidNumber
    FAILED

Comparing:
'CN=REDACTED5,CN=Computers,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED5,CN=Computers,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Difference in attribute values:
        lastLogonTimestamp =>
['SMALLVALUE']
['BIGVALUE']
    FAILED

Comparing:
'CN=REDACTED6,CN=Computers,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=REDACTED6,CN=Computers,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Difference in attribute values:
        lastLogonTimestamp =>
['SMALLVALUE']
['BIGVALUE']
    FAILED

Comparing:
'CN=sven.schwedas,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-sem.ad.tao.at]
'CN=sven.schwedas,CN=Users,DC=ad,DC=tao,DC=at' [ldap://graz-dc-1b.ad.tao.at]
    Difference in attribute values:
        objectClass =>
['organizationalPerson', 'person', 'posixAccount', 'taoUser', 'top', 'user']
['organizationalPerson', 'person', 'posixAccount', 'top', 'ucsUser', 'user']
    FAILED

* Result for [DOMAIN]: FAILURE

SUMMARY
---------

Attributes found only in ldap://graz-dc-sem.ad.tao.at:

    msSFU30NisDomain
    gidNumber

Attributes with different values:

    objectClass
    lastLogonTimestamp

* Comparing [CONFIGURATION] context...

* Objects to be compared: 1630

* Result for [CONFIGURATION]: SUCCESS

* Comparing [SCHEMA] context...

* Objects to be compared: 1566

* Result for [SCHEMA]: SUCCESS

* Comparing [DNSDOMAIN] context...

* Objects to be compared: 176

* Result for [DNSDOMAIN]: SUCCESS

* Comparing [DNSFOREST] context...

* Objects to be compared: 21

* Result for [DNSFOREST]: SUCCESS
.. Next check..
Running : samba-tool drs showrepl
     failures don't match
    successes don't match
     failures don't match
    successes don't match
     failures don't match
    successes don't match

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Hai Sven,

Sorry for the long wait, i had some things todo first here.


> -----Oorspronkelijk bericht-----
> Van: Sven Schwedas [mailto:[hidden email]]
> Verzonden: woensdag 6 september 2017 16:06
> Aan: L.P.H. van Belle; [hidden email]
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
>
> On 2017-09-06 09:28, L.P.H. van Belle wrote:
> >>> I suggest the following, move fsmo roles to villach-dc and
> >> check database replications.
> >>
> >> DB replication is already spewing errors, what am I to
> look out for?
> > Ok, get my check db script, run it from any dc. And post me
> the output.
>
> Output attached. Seems like all servers but graz-dc-sem have
> some stuff wrong, just wonderful.
Ok base on the log,
graz-dc-sem.ad.tao.at is the most complete/correct server.

>
> > https://github.com/thctlo/samba4/blob/master/samba-check-db-repl.sh
>
> Just FYI, something's wonky with the script. Bash trips up on
> CRLF line endings (everywhere) and 0xC2 control characters
> (ll. 260-261) sprinkled through the file. Had to clean that
> up before it actually ran without syntax errors.
Yes, sorry, i should have send this link.
https://raw.githubusercontent.com/thctlo/samba4/master/samba-check-db-repl.sh 


>
> >>> Remove the most faulty one first, graz-dc-1b, from the
> >> domain. ( check
> >>> and cleanup DNS and AD! Very important )
> >>
> >> What to check for? What to clean up?
> > Ah, thats hard to tell, this depends a bit on the errors.
> > I search/look for the left overs, first with RSAT tools and
> samba-tool, then with ApacheStudio.
> > I look for hostnames/UUID/ things like that, but this is
> only done if all other options did not work.
> > But it depends on the errors/warnings i see/get.
>
> None of the differences look like they could cause the
> replication errors, looks more like they're just the results.
Faulty GUID/UUID's can and wil result in replication errors yes..

>
> >>>>> Then remove a failty server and re-add it as a new installed DC.
> >>>>> ( the good DS with FSMO)
> >>>>> First backup: /var/lib/samba/private/secrets.keytab
> >>>>> Remove the incorrect entries from keytab file with ktutil rkt
> >>>>> /var/lib/samba/private/secrets.keytab
> >>>>> list -e -t
> >>>>
> >>>> Might as well just nuke graz-dc-sem and add a complete
> new DC from
> >>>> scratch, no?
> >>> No, and yes, but i preffer no, not needed (yet).
> >>> Start with the keytab cleanup
> >>> Check the dns record if the uuid A PTR and hostnames
> >> resolve to the correct server.
> >>> If thats the case, then no, cleanup of keytab is, i think,
> >> sufficient.
> >>
> >> Just to confirm the order: Clean up the keytab, if that
> doesn't work,
> >> start removing servers?
> > Almost. Backup then ...   Cleanup keytab of the server.
>
> I'll try that next, unless you find something shady in the report.
>
> >>> Yes, if its really a mess. ;-)
> >>> Then, first a an new DC, then remove, just make sure you
> >> always have 2
> >>> dc's up and running (correctly)
> >>
> >> Servers in Villach seem to run fine, thank $DEITY, so I'll
> leave them
> >> alone for now.
> > Ok, thats good, run the check-db script and post the
> complete output for me.
> >
> >>
> >>>>> Now re-provision and you should have correct working
> DC's again.
> >>>>>
> >>>>> ! Before re-provisioning, make sure all OLD records dns and
> >>>> AD are gone.
> >>>>
> >>>> I still have undeleteable replication records from the
> last time I
> >>>> had to nuke a DC, nobody replied to my emails on that issue.
> >>>
> >>> Ok, now, im out of office in about 10 min, but mail that
> >> subject for me again> I'll have a look.
> >>
> >> First message on that topic:
> >> https://lists.samba.org/archive/samba/2017-March/207429.html
> > Ok, this one, track down both uuid's, checkout which which
> hostname belongs with these.
>
> Going by the output of `samba-tool drs showrepl` and sam.ldb,
> the GUIDs are as follows:
>
> graz-dc-sem 160f5a53-5c29-4a83-aeee-6cb1dbabeed7
> graz-dc-bis 7e4973ba-4093-4523-a70f-7caa4845e34d (not in sam.ldb)
> graz-dc-1b bcffbad8-1add-46b9-bf69-90e52c0f09ea
> villach-dc-sem eb5f9772-cd8f-4cde-9629-f1898c94aedd
> villach-dc-bis e1569c90-50f9-4bb5-bd85-79145e3ff6fd
>
> villach-sem/bis want to replicate to the dead and removed
> graz-dc-bis for some reason, but don't have its GUID in their
> sam.ldb either.
Ok, can you do a manualy check on graz-dc-sem and villach-dc-sem
Both command on each server.
samba-tool dbcheck
And
samba-tool dbcheck --cross-nc

Error, post them.

>
> > Basicly https://wiki.samba.org/index.php/Demoting_a_Samba_AD_DC
> > In based on the Demoteing wiki example.
> > I do the same steps as shown there. Now the last three
> pictures on the site shows where to look.
> > At the site and Service, go through very folder, and check
> if it is as it should be.
>
> I already checked it back then, and double checked it now.
> ADUC, ADSS and DNS are all three clean and contain no
> reference to either the old server name or its GUID.
>
> > https://lists.samba.org/archive/samba/2017-March/207460.html
> > Between 2 and 3, there the problem starts
> >>>  – I noticed a typo in the server's `netbios name`
> setting, corrected it, and restarted the DC.
> > 3. Yes, for the new hostname, the old hostname is as left
> over in the ADDC DB and/or DNS.
> >
> > This name GRAZ-DC-BIS, and the name with the typo. The GUID
> for these is where to look info.
>
> Yeah, but where?
Now this is here ApacheStudio is very handy, but again, dont rush things here.
With ApacheStu.. Connect to the AD, and search for the faulty GUID/UUID's
Same for the hostname.

Ow did i tell you to make a backup first..  ;-) make it 2. ;-)


>
> > Step 6. ah the point of origin of you problems with of the
> current post?
>
> Hell if I know, but might be.
>
> > 7. dnsmasq? Ok, i just hope these are not running on the DC's.
>
> It's running on the gateways to cache the DCs' responses and
> handle some auxiliary stuff. ad.tao.at and all subdomains are
> transparently forwarded to the DCs, no difference in
> responses for _msdsc etc. between them and querying the DCs directly.
Ok, thats fine then.

>
> >> Last message, where I mentioned the replication bug:
> >> https://lists.samba.org/archive/samba/2017-April/207918.html
> >>
> >>> Own and if you dont use it, ApacheDirectoryStudio can help
> >> a lot with cleanup of these kind of things.
> >>
> >> Currently I'm using the ADSI MMC snap-in, any downsides
> compared to
> >> ADS?
> > I dont know, never used ADS :-/
> >
> > Track done these : GUID's, the hostname's, ipnumbers A and
> PTR records
> > 7e4973ba-4093-4523-a70f-7caa4845e34d
> > d613fa11-064b-4bcc-ab01-20264f870f47
> > (how, see Verifying and Creating the objectGUID Record  
> >
> https://wiki.samba.org/index.php/Verifying_and_Creating_a_DC_DNS_Recor
> > d)
>
> Neither of the two return any results on any DC (or on the
> dnsmasq servers), but the GUIDs for the 4 currently existing
> DCs work fine. This matches the data from the RSAT tools.


Now, last, which is an option.
If one server hold a good and correct database, you can sync that one to the other servers.
But the database must be correct. ( and backuped 2 x )

samba-tool dbcheck --help gives also few extra options but i never used them so i cant tell much of these are usefull.
  --reindex             force database re-index
  --reset-well-known-acls
  --cross-ncs  

Rowland, can you give a educated answer on these also.

Greetz,

Louis

 


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On Fri, 8 Sep 2017 10:37:56 +0200
"L.P.H. van Belle via samba" <[hidden email]> wrote:


> > Neither of the two return any results on any DC (or on the
> > dnsmasq servers), but the GUIDs for the 4 currently existing
> > DCs work fine. This matches the data from the RSAT tools.
>
>
> Now, last, which is an option.
> If one server hold a good and correct database, you can sync that one
> to the other servers. But the database must be correct. ( and
> backuped 2 x )
>
> samba-tool dbcheck --help gives also few extra options but i never
> used them so i cant tell much of these are usefull.
> --reindex             force database re-index --reset-well-known-acls
>   --cross-ncs  
>
> Rowland, can you give a educated answer on these also.
>

You seem to have covered everything Louis, except I noticed the mention
of 'dnsmasq servers', I think the OP needs to expand on where these are
being used.

Rowland

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
Thanks Rowland,

Very appriciated.
The dnsmasq servers are explained, these are no problem in his setup sofar i could tell/see.


Greetz,

Louis
 

> -----Oorspronkelijk bericht-----
> Van: samba [mailto:[hidden email]] Namens
> Rowland Penny via samba
> Verzonden: vrijdag 8 september 2017 10:50
> Aan: [hidden email]
> Onderwerp: Re: [Samba] Server GC/name.dom/dom is not
> registered with our KDC: Miscellaneous failure (see text):
> Server (GC/name/dom@DOM) unknown
>
> On Fri, 8 Sep 2017 10:37:56 +0200
> "L.P.H. van Belle via samba" <[hidden email]> wrote:
>
>
> > > Neither of the two return any results on any DC (or on
> the dnsmasq
> > > servers), but the GUIDs for the 4 currently existing DCs
> work fine.
> > > This matches the data from the RSAT tools.
> >
> >
> > Now, last, which is an option.
> > If one server hold a good and correct database, you can
> sync that one
> > to the other servers. But the database must be correct. (
> and backuped
> > 2 x )
> >
> > samba-tool dbcheck --help gives also few extra options but i never
> > used them so i cant tell much of these are usefull.
> > --reindex             force database re-index
> --reset-well-known-acls
> >   --cross-ncs
> >
> > Rowland, can you give a educated answer on these also.
> >
>
> You seem to have covered everything Louis, except I noticed
> the mention of 'dnsmasq servers', I think the OP needs to
> expand on where these are being used.
>
> Rowland
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>


--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On Fri, 8 Sep 2017 12:03:53 +0200
"L.P.H. van Belle via samba" <[hidden email]> wrote:

> Thanks Rowland,
>
> Very appriciated.
> The dnsmasq servers are explained, these are no problem in his setup
> sofar i could tell/see.
>
>

Yes, but do the dnsmasq servers hold all the AD records ?

Rowland

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-08 12:26, Rowland Penny via samba wrote:

> On Fri, 8 Sep 2017 12:03:53 +0200
> "L.P.H. van Belle via samba" <[hidden email]> wrote:
>
>> Thanks Rowland,
>>
>> Very appriciated.
>> The dnsmasq servers are explained, these are no problem in his setup
>> sofar i could tell/see.
>>
> Yes, but do the dnsmasq servers hold all the AD records ?

Define "hold"; they're used as caching servers, but all queries for
ad.tao.at and subdomains are forwarded to the DCs:

> server=/ad.tao.at/192.168.x #repeated for all DCs
> server=/x.168.192.in-addr.arpa/x # repeated for all DCs

filterwin2k etc. is **not** enabled in dnsmasq, so no queries are
blocked, everything is forwarded.

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On Fri, 8 Sep 2017 12:43:40 +0200
Sven Schwedas via samba <[hidden email]> wrote:

> On 2017-09-08 12:26, Rowland Penny via samba wrote:
> > On Fri, 8 Sep 2017 12:03:53 +0200
> > "L.P.H. van Belle via samba" <[hidden email]> wrote:
> >
> >> Thanks Rowland,
> >>
> >> Very appriciated.
> >> The dnsmasq servers are explained, these are no problem in his
> >> setup sofar i could tell/see.
> >>
> > Yes, but do the dnsmasq servers hold all the AD records ?
>
> Define "hold"; they're used as caching servers, but all queries for
> ad.tao.at and subdomains are forwarded to the DCs:
>
> > server=/ad.tao.at/192.168.x #repeated for all DCs
> > server=/x.168.192.in-addr.arpa/x # repeated for all DCs
>
> filterwin2k etc. is **not** enabled in dnsmasq, so no queries are
> blocked, everything is forwarded.
>

The problem I have (and it might be me worrying over nothing) is that
quite a few of the AD records point to Multiple DCs and dnsmasq might
only retain the info for the DC it finds first. if it does this and
next time it is asked for the record, it returns what it knows, but
this DC has gone off line, what happens ?

Rowland
 

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-08 13:02, Rowland Penny via samba wrote:

> On Fri, 8 Sep 2017 12:43:40 +0200
> Sven Schwedas via samba <[hidden email]> wrote:
>
>> On 2017-09-08 12:26, Rowland Penny via samba wrote:
>>> On Fri, 8 Sep 2017 12:03:53 +0200
>>> "L.P.H. van Belle via samba" <[hidden email]> wrote:
>>>
>>>> Thanks Rowland,
>>>>
>>>> Very appriciated.
>>>> The dnsmasq servers are explained, these are no problem in his
>>>> setup sofar i could tell/see.
>>>>
>>> Yes, but do the dnsmasq servers hold all the AD records ?
>>
>> Define "hold"; they're used as caching servers, but all queries for
>> ad.tao.at and subdomains are forwarded to the DCs:
>>
>>> server=/ad.tao.at/192.168.x #repeated for all DCs
>>> server=/x.168.192.in-addr.arpa/x # repeated for all DCs
>>
>> filterwin2k etc. is **not** enabled in dnsmasq, so no queries are
>> blocked, everything is forwarded.
>>
>
> The problem I have (and it might be me worrying over nothing) is that
> quite a few of the AD records point to Multiple DCs and dnsmasq might
> only retain the info for the DC it finds first. if it does this and
> next time it is asked for the record, it returns what it knows, but
> this DC has gone off line, what happens ?

dnsmasq handles multicast responses correctly:

> [creshal@medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV @192.168.17.1
>
> ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV @192.168.17.1
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4753
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_ldap._tcp.dc._msdcs.ad.tao.at. IN SRV
>
> ;; ANSWER SECTION:
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 graz-dc-sem.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 villach-dc-sem.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 villach-dc-bis.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 graz-dc-1b.ad.tao.at.
>
> ;; AUTHORITY SECTION:
> _msdcs.ad.tao.at. 3600 IN SOA graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
>
> ;; Query time: 4 msec
> ;; SERVER: 192.168.17.1#53(192.168.17.1)
> ;; WHEN: Fre Sep 08 13:20:24 CEST 2017
> ;; MSG SIZE  rcvd: 228
>
> [creshal@medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV @192.168.17.65
>
> ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV @192.168.17.65
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20251
> ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;_ldap._tcp.dc._msdcs.ad.tao.at. IN SRV
>
> ;; ANSWER SECTION:
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 graz-dc-sem.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 villach-dc-sem.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 villach-dc-bis.ad.tao.at.
> _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0 100 389 graz-dc-1b.ad.tao.at.
>
> ;; AUTHORITY SECTION:
> _msdcs.ad.tao.at. 3600 IN SOA graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
>
> ;; Query time: 3 msec
> ;; SERVER: 192.168.17.65#53(192.168.17.65)
> ;; WHEN: Fre Sep 08 13:20:28 CEST 2017
> ;; MSG SIZE  rcvd: 228

First response is dnsmasq, second response is querying a DC directly. No
difference. TTLs are honoured as well.


--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On Fri, 8 Sep 2017 13:21:34 +0200
Sven Schwedas via samba <[hidden email]> wrote:

> On 2017-09-08 13:02, Rowland Penny via samba wrote:
> > On Fri, 8 Sep 2017 12:43:40 +0200
> > Sven Schwedas via samba <[hidden email]> wrote:
> >
> >> On 2017-09-08 12:26, Rowland Penny via samba wrote:
> >>> On Fri, 8 Sep 2017 12:03:53 +0200
> >>> "L.P.H. van Belle via samba" <[hidden email]> wrote:
> >>>
> >>>> Thanks Rowland,
> >>>>
> >>>> Very appriciated.
> >>>> The dnsmasq servers are explained, these are no problem in his
> >>>> setup sofar i could tell/see.
> >>>>
> >>> Yes, but do the dnsmasq servers hold all the AD records ?
> >>
> >> Define "hold"; they're used as caching servers, but all queries for
> >> ad.tao.at and subdomains are forwarded to the DCs:
> >>
> >>> server=/ad.tao.at/192.168.x #repeated for all DCs
> >>> server=/x.168.192.in-addr.arpa/x # repeated for all DCs
> >>
> >> filterwin2k etc. is **not** enabled in dnsmasq, so no queries are
> >> blocked, everything is forwarded.
> >>
> >
> > The problem I have (and it might be me worrying over nothing) is
> > that quite a few of the AD records point to Multiple DCs and
> > dnsmasq might only retain the info for the DC it finds first. if it
> > does this and next time it is asked for the record, it returns what
> > it knows, but this DC has gone off line, what happens ?
>
> dnsmasq handles multicast responses correctly:
>
> > [creshal@medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.1
> >
> > ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.1 ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4753
> > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 1,
> > ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;_ldap._tcp.dc._msdcs.ad.tao.at. IN SRV
> >
> > ;; ANSWER SECTION:
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 graz-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 villach-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 villach-dc-bis.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 graz-dc-1b.ad.tao.at.
> >
> > ;; AUTHORITY SECTION:
> > _msdcs.ad.tao.at. 3600 IN SOA
> > graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
> >
> > ;; Query time: 4 msec
> > ;; SERVER: 192.168.17.1#53(192.168.17.1)
> > ;; WHEN: Fre Sep 08 13:20:24 CEST 2017
> > ;; MSG SIZE  rcvd: 228
> >
> > [creshal@medea ~]$ dig _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.65
> >
> > ; <<>> DiG 9.11.2 <<>> _ldap._tcp.dc._msdcs.ad.tao.at SRV
> > @192.168.17.65 ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20251
> > ;; flags: qr aa rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 1,
> > ADDITIONAL: 0
> >
> > ;; QUESTION SECTION:
> > ;_ldap._tcp.dc._msdcs.ad.tao.at. IN SRV
> >
> > ;; ANSWER SECTION:
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 graz-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 villach-dc-sem.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 villach-dc-bis.ad.tao.at.
> > _ldap._tcp.dc._msdcs.ad.tao.at. 900 IN SRV 0
> > 100 389 graz-dc-1b.ad.tao.at.
> >
> > ;; AUTHORITY SECTION:
> > _msdcs.ad.tao.at. 3600 IN SOA
> > graz-dc-sem.ad.tao.at. hostmaster.ad.tao.at. 29 900 600 86400 0
> >
> > ;; Query time: 3 msec
> > ;; SERVER: 192.168.17.65#53(192.168.17.65)
> > ;; WHEN: Fre Sep 08 13:20:28 CEST 2017
> > ;; MSG SIZE  rcvd: 228
>
> First response is dnsmasq, second response is querying a DC directly.
> No difference. TTLs are honoured as well.
>
>

OK, you have convinced me ;-)

Seeing how you seem to know the required 'magic', do you feel up to
sharing it, if you do I will add a page to the Samba wiki.

You can send it off list if you like.

Rowland
 

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
On 2017-09-08 14:21, Rowland Penny via samba wrote:
> OK, you have convinced me ;-)

If you know any other part of AD DNS that is tricky, I'd be interested
to know before AD blows up again. ;-)

> Seeing how you seem to know the required 'magic', do you feel up to
> sharing it, if you do I will add a page to the Samba wiki.

What magic? How to set up dnsmasq as caching proxy? Sure, I can make a
commented example config file.

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
In reply to this post by Samba - General mailing list
On 2017-09-08 10:37, L.P.H. van Belle wrote:
> Hai Sven,
>
> Sorry for the long wait, i had some things todo first here.

's fine. It's not like I don't have other stuff to worry about either.

>> -----Oorspronkelijk bericht-----
>>>>> I suggest the following, move fsmo roles to villach-dc and
>>>> check database replications.
>>>>
>>>> DB replication is already spewing errors, what am I to
>>>> look out for?
>>> Ok, get my check db script, run it from any dc. And post me
>>> the output.
>>
>> Output attached. Seems like all servers but graz-dc-sem have
>> some stuff wrong, just wonderful.
> Ok base on the log,
> graz-dc-sem.ad.tao.at is the most complete/correct server.

And also the one with the keytab problems. :(

>>>>>>> Then remove a failty server and re-add it as a new installed DC.
>>>>>>> ( the good DS with FSMO)
>>>>>>> First backup: /var/lib/samba/private/secrets.keytab
>>>>>>> Remove the incorrect entries from keytab file with ktutil rkt
>>>>>>> /var/lib/samba/private/secrets.keytab
>>>>>>> list -e -t
>>>>>>
>>>>> Start with the keytab cleanup
>>>>> Check the dns record if the uuid A PTR and hostnames
>>>>> resolve to the correct server.
>>>>> If thats the case, then no, cleanup of keytab is, i think,
>>>>> sufficient.
>>>>
>>>> Just to confirm the order: Clean up the keytab, if that
>>>> doesn't work,
>>>> start removing servers?
>>> Almost. Backup then ...   Cleanup keytab of the server.
>>
>> I'll try that next, unless you find something shady in the report.

While going through the records with Directory Studio I noticed that the
duplicate keytab entries are mirrored by servicePrincipalName entries in
CN=GRAZ-DC-SEM,OU=Domain Controllers,DC=ad,DC=tao,DC=at

Which should I clean up, and in what order? LDAP first, then keytab?
Just LDAP?

>>>> First message on that topic:
>>>> https://lists.samba.org/archive/samba/2017-March/207429.html
>>> Ok, this one, track down both uuid's, checkout which which
>>> hostname belongs with these.
>>
>> Going by the output of `samba-tool drs showrepl` and sam.ldb,
>> the GUIDs are as follows:
>>
>> graz-dc-sem 160f5a53-5c29-4a83-aeee-6cb1dbabeed7
>> graz-dc-bis 7e4973ba-4093-4523-a70f-7caa4845e34d (not in sam.ldb)
>> graz-dc-1b bcffbad8-1add-46b9-bf69-90e52c0f09ea
>> villach-dc-sem eb5f9772-cd8f-4cde-9629-f1898c94aedd
>> villach-dc-bis e1569c90-50f9-4bb5-bd85-79145e3ff6fd
>>
>> villach-sem/bis want to replicate to the dead and removed
>> graz-dc-bis for some reason, but don't have its GUID in their
>> sam.ldb either.
> Ok, can you do a manualy check on graz-dc-sem and villach-dc-sem
> Both command on each server.
> samba-tool dbcheck
> And
> samba-tool dbcheck --cross-nc
>
> Error, post them.

About that… villach-dc-sem is down because its VM host went poof
yesterday. :/ Gonna get it repaired at some point next week.

On graz-dc-sem, samba-tool dbcheck shows zero errors. --cross-nc gives:

> Error: governsID CN=ucsUser,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 1.3.6.1.4.1.19414.3.2.2 already exists as an attributeId or governsId
> Error: governsID CN=taoSharedFolder,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 1.3.6.1.4.1.19414.3.2.4 already exists as an attributeId or governsId
> Error: governsID CN=taoMailingList,CN=Schema,CN=Configuration,DC=ad,DC=tao,DC=at on 1.3.6.1.4.1.19414.3.2.3 already exists as an attributeId or governsId

Those are presumably from me fucking around with custom LDAP attributes
years ago and don't seem to be related. I hope.

>>>>>  – I noticed a typo in the server's `netbios name`
>> setting, corrected it, and restarted the DC.
>>> 3. Yes, for the new hostname, the old hostname is as left
>> over in the ADDC DB and/or DNS.
>>>
>>> This name GRAZ-DC-BIS, and the name with the typo. The GUID
>> for these is where to look info.
>>
>> Yeah, but where?
> Now this is here ApacheStudio is very handy, but again, dont rush things here.
> With ApacheStu.. Connect to the AD, and search for the faulty GUID/UUID's
> Same for the hostname.
>
> Ow did i tell you to make a backup first..  ;-) make it 2. ;-)

No results for either the old name, nor the new name, nor the GUID, on
any server.

How is `drs showrepl` giving me the UUID for something that's nowhere in
LDAP?

> Now, last, which is an option.
> If one server hold a good and correct database, you can sync that one to the other servers.
> But the database must be correct. ( and backuped 2 x )

So

1. Back up graz-dc-sem
2. purge the duplicate keytab/SPN magic voodoo somehow (see above)
3. Force sync?

> samba-tool dbcheck --help gives also few extra options but i never used them so i cant tell much of these are usefull.
>   --reindex             force database re-index
>   --reset-well-known-acls
>   --cross-ncs  

--
Mit freundlichen Grüßen, / Best Regards,
Sven Schwedas, Systemadministrator
Mail/XMPP [hidden email] | Skype sven.schwedas
TAO Digital | Lendplatz 45 | A8020 Graz
https://www.tao-digital.at | Tel +43 680 301 7167

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
Reply | Threaded
Open this post in threaded view
|

Re: Server GC/name.dom/dom is not registered with our KDC: Miscellaneous failure (see text): Server (GC/name/dom@DOM) unknown

Samba - General mailing list
In reply to this post by Samba - General mailing list
On Fri, 8 Sep 2017 14:31:21 +0200
Sven Schwedas via samba <[hidden email]> wrote:

> On 2017-09-08 14:21, Rowland Penny via samba wrote:
> > OK, you have convinced me ;-)
>
> If you know any other part of AD DNS that is tricky, I'd be interested
> to know before AD blows up again. ;-)
>
> > Seeing how you seem to know the required 'magic', do you feel up to
> > sharing it, if you do I will add a page to the Samba wiki.
>
> What magic? How to set up dnsmasq as caching proxy? Sure, I can make a
> commented example config file.
>

Well, if you don't know how to do something, then it is 'magic' when it
happens ;-)

Rowland

--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba
12