Secondary DC not registered with KDC

ssureshot ssureshot at gmail.com
Sat Jun 9 07:02:15 MDT 2012


On 06/08/2012 06:15 PM, Andrew Bartlett wrote:
> On Fri, 2012-06-08 at 09:58 -0400, Aaron E. wrote:
>> On 06/07/2012 07:22 PM, Andrew Bartlett wrote:
>>> On Thu, 2012-06-07 at 11:51 -0400, Aaron E. wrote:
>>>> I'm scratching my head with this.. Is this a normal error with debug 3?
>>>> Any help in direction or troubleshooting with this is appreciated. Any
>>>> searches I can perform on the DB or items I need to delete or add?
>>>>
>>>>
>>>>     I believe this has been a good DB since alpha 18 or 19.. This is the
>>>> DB that I would like to turn production if I can clean up the errors and
>>>> get Secondary DC DNS worked through and working.. I'd hate to have to
>>>> reconfigure my terminal servers and group policy, squid and mailservers
>>>> that I've setup tuned to this installation.. I would love to start
>>>> migrating users in the next few weeks ..
>>> Can you do that search again, but like this:
>>>
>>> ldbsearch -H ldap://astrodc1
>>> servicePrincipalName=ldap/ASTRODC2.astrointernal.com
>>>
>>> If we have two entries with astrodc2, then we don't know which one to
>>> use.  We should probably also work out if we should have prevented that
>>> happening in the first place.
>>>
>>> Andrew Bartlett
>>>
>>>
>> There are two entries once of them looks like the primary DC though?? If
>> I run the same search with
>> servicePrincipalName=ldap/ASTRODC1.astrointernal.com it only returns the
>> one entry.
>>
>> GENSEC backend 'gssapi_spnego' registered
>> GENSEC backend 'gssapi_krb5' registered
>> GENSEC backend 'gssapi_krb5_sasl' registered
>> GENSEC backend 'sasl-DIGEST-MD5' registered
>> GENSEC backend 'schannel' registered
>> GENSEC backend 'spnego' registered
>> GENSEC backend 'ntlmssp' registered
>> GENSEC backend 'krb5' registered
>> GENSEC backend 'fake_gssapi_krb5' registered
>> interpret_interface: using netmask value 32 from config file on
>> interface bond0:n01
>> interpret_interface: using netmask value 32 from config file on
>> interface bond0:n01
>> # record 1
>> dn: CN=ASTRODC1,OU=Domain Controllers,DC=astrointernal,DC=com
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com/ASTROINTERNAL
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com/ASTROINTERNAL
>> servicePrincipalName: GC/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName:
>> # record 2
>> dn: CN=ASTRODC2,OU=Domain Controllers,DC=astrointernal,DC=com
>> servicePrincipalName: HOST/ASTRODC2
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com
>> servicePrincipalName: GC/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName:
>> E3514235-4B06-11D1-AB04-00C04FC2DCD2/be899af6-ed2d-482b-
>>    946b-c00e89915cc2/astrointernal.com
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com/ASTROINTERNAL
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com/ASTROINTERNAL
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com
>> servicePrincipalName: HOST/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName: ldap/ASTRODC2.astrointernal.com/astrointernal.com
>> servicePrincipalName:
>> ldap/be899af6-ed2d-482b-946b-c00e89915cc2._msdcs.astroin
>>    ternal.com
>> servicePrincipalName: ldap/ASTRODC2
>> servicePrincipalName: RestrictedKrbHost/ASTRODC2
>> servicePrincipalName: RestrictedKrbHost/ASTRODC2.astrointernal.com
>> distinguishedName: CN=ASTRODC2,OU=Domain Controllers,DC=astrointernal,DC=com
> Ok, this certainly would seem to be the problem.  Do you have any idea
> how this might have happened?
>
> Did you ever rename your DCs?
>
> Andrew Bartlett
>
The only possibility I can remotely think of and this may not even be 
the case.. Is it possible this could have happened if the netbios name 
in the smb.conf was at one point astrodc1 for a few days? Would that 
have added entries like this to the DB automatically? I remember copying 
the PDC smb.conf to the BDC in order to copy the 20 shares that I had 
changed and I did not change the name untill I realized replication 
wasn't working properly from the secondary.. Brain Fart moment on my part..

Is it as easy as just removing this entry of is this engrained real deep 
in the DB? Should I demote the BDC and try to clean up the DB then re-join?


More information about the samba-technical mailing list