samba - Apr 2010 - PDC: System SID missing / inconsistent with domain SID

Hello,

I recently noticed a problem on our PDC (samba 3.0.32
on SLES 10 SP2) which I kind of know how to solve after
web research but I am unclear about the possible
consequences for our domain and clients.

The situation is this:
Originally samba was set up on this machine to test. Back
then its hostname was infrahostnew, so there is a SID for
that NETBIOS name in secrets.tdb. When the PDC went in
production, we had to change the hostname to infrahost.
We then provisioned our domain MYDOMAIN. Now there is also
a SID for MYDOMAIN in secrets.tdb which is different than
the SID of infrahostnew. Also there is no SID at all for
the new NETBIOS name infrahost. This causes for example
net getlocalsid to fail.

My research suggests that the NETBIOS name SID of the PDC
infrahost should be the same as the domain SID, is that
correct? Also, I found an article that dealt with inconsistent
SIDs; it suggested to set the NETBIOS SID to be the same
as the domain SID. But this article dealt with the case
that there actually _is_ a NETBIOS SID in secrets.tdb but
it's not the same as the domain SID. This is not our case
however since there is no SID at all for the NETBIOS name.

We haven't noticed any problems because of this at all,
I just stumbled upon it when I went to check the SIDs
routinely. How would you suggest I proceed in this situation?
Should we set the NETBIOS SID to be the same as the domain
SID with net setlocalsid? What possible consequences could
there be? We are very concerned that this may introduce problems
for our clients that we don't have at the moment. But I
wouldn't like to keep things in an inconsistent state like
this either.

I'd be glad for any insights.

Regards
Frank

I've recently come across the same situation, while migrating a 3.0.33 
PDC host to 3.6.9. I had renamed the old host some time ago from LANYARD 
to TACS-DC. The old host still functions fine, except for not being able 
to get its own SID.

Old DC host:
[root at tacs-dc samba]# net getdomainsid
Could not fetch local SID
[root at tacs-dc samba]# tdbdump secrets.tdb
{
key(19) = "SECRETS/DOMGUID/R3I"
data(16) = "\DF\DDA\01\F62\8CG\A8\80\B4\1CFM\1D\0B"
}
{
key(19) = "SECRETS/SID/LANYARD"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00n\86\90\05\D9\D2\ED
(...)"
}
{
key(15) = "SECRETS/SID/R3I"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00n\86\90\05\D9\D2\ED
(...)"
}
[root at tacs-dc samba]# net rpc trustdom list -U shubes
Password:
Trusted domains list:

none

Trusting domains list:

none
[root at tacs-dc samba]#


I've migrated everything (accounts, tdb files) to a new host, and 
changed the LANYARD record to TACS-DC in the secrets.tdb, which 
corresponds to the new hostname:
[root at tacs-dc private]# net getdomainsid
SID for local machine TACS-DC is: S-1-5-21-93357678-3857568473-1617xxxxxx
SID for domain R3I is: S-1-5-21-93357678-3857568473-1617xxxxxx
[root at tacs-dc private]# tdbdump secrets.tdb
{
key(19) = "SECRETS/DOMGUID/R3I"
data(16) = "\DF\DDA\01\F62\8CG\A8\80\B4\1CFM\1D\0B"
}
{
key(19) = "SECRETS/SID/TACS-DC"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00n\86\90\05\D9\D2\ED
(...)"
}
{
key(15) = "SECRETS/SID/R3I"
data(68) = "\01\04\00\00\00\00\00\05\15\00\00\00n\86\90\05\D9\D2\ED
(...)"
}
[root at tacs-dc private]# net rpc trustdom list -U shubes
Unable to find a suitable server for domain R3I
Couldn't connect to domain controller: NT_STATUS_UNSUCCESSFUL
[root at tacs-dc private]#

Everything appears to be working, except that the new host isn't 
recognized as a domain controller. Note that workstations are able to 
log on to the domain using the new DC host though.

I'm guessing that adding a TACS-DC record to the old host would fix the 
problem of not being able to get its SID.

I'm also guessing that adding a LANYARD record to the new host *might* 
make it recognize that it's a domain controller. I hope to test this 
later today, when users are gone.

It appears to me that the original host name which created the domain is 
stored in some way somewhere else (I see it in the USER_ records in the 
passdb.tdb file). If so, can this somehow be changed? The documentation 
I've found all says how to migrate to another host keeping the host name 
the same, but I haven't been able to find anything about changing the 
host name.

Does anyone have any other ideas why this new host isn't being 
recognized as a DC?

Thanks.

-- 
-Eric 'shubes'
On 04/29/2010 03:08 AM, Frank Stanek wrote:
> Hello,
>
> I recently noticed a problem on our PDC (samba 3.0.32
> on SLES 10 SP2) which I kind of know how to solve after
> web research but I am unclear about the possible
> consequences for our domain and clients.
>
> The situation is this:
> Originally samba was set up on this machine to test. Back
> then its hostname was infrahostnew, so there is a SID for
> that NETBIOS name in secrets.tdb. When the PDC went in
> production, we had to change the hostname to infrahost.
> We then provisioned our domain MYDOMAIN. Now there is also
> a SID for MYDOMAIN in secrets.tdb which is different than
> the SID of infrahostnew. Also there is no SID at all for
> the new NETBIOS name infrahost. This causes for example
> net getlocalsid to fail.
>
> My research suggests that the NETBIOS name SID of the PDC
> infrahost should be the same as the domain SID, is that
> correct? Also, I found an article that dealt with inconsistent
> SIDs; it suggested to set the NETBIOS SID to be the same
> as the domain SID. But this article dealt with the case
> that there actually _is_ a NETBIOS SID in secrets.tdb but
> it's not the same as the domain SID. This is not our case
> however since there is no SID at all for the NETBIOS name.
>
> We haven't noticed any problems because of this at all,
> I just stumbled upon it when I went to check the SIDs
> routinely. How would you suggest I proceed in this situation?
> Should we set the NETBIOS SID to be the same as the domain
> SID with net setlocalsid? What possible consequences could
> there be? We are very concerned that this may introduce problems
> for our clients that we don't have at the moment. But I
> wouldn't like to keep things in an inconsistent state like
> this either.
>
> I'd be glad for any insights.
>
> Regards
> Frank
>