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@tacs-dc samba]# net getdomainsid
Could not fetch local SID
[root@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@tacs-dc samba]# net rpc trustdom list -U shubes
Password:
Trusted domains list:
none
Trusting domains list:
none
[root@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@tacs-dc private]# net getdomainsid
SID for local machine TACS-DC is: S-1-5-21-93357678-3857568473-1617xx
SID for domain R3I is: S-1-5-21-93357678-3857568473-1617xx
[root@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@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@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
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
