Secondary DC not registered with KDC

[Aaron E.]

On 06/11/2012 05:25 AM, Andrew Bartlett wrote:
> On Sat, 2012-06-09 at 09:02 -0400, ssureshot wrote:
>> 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?
>
> Yes, that would do it.
>
>> Would that
>> have added entries like this to the DB automatically?
>
> Yes.
>
>>   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?
>
> Just edit the DB.
>
>> Should I demote the BDC and try to clean up the DB then re-join?
>
> It would be best to edit the entry.
>
> Andrew Bartlett
>

I was able to clean this up easily using an LDAP administration tool.. 
Thank you for the Help Andrew..

Now on to the next issue..