The SID Problem
The Trios Exacerbation
Resolution by Local User Profile
Backgrounders
From: "Robert Bachellor" <rbachellor@mybizz.net>
Newsgroups: microsoft.public.backoffice.smallbiz
Subject: Re: start over
If you want to keep the username and computer accounts, you can make an ERD
(Emergency Repair Disk). Then re-install SBS on an empty drive. After
everything's up and running, rename the file on install floppy #2 from
winnt.sif to some temporary name, I use winnt.sik. Re-boot the machine
using the floppies. This will let you go into the repair mode and give you
the option of restoring the SAM. That should recreate the SIDs and
accounts.
Subject: Re: start over
From: "Hollis D. Paul"
I do wish this message had bubbled up when I was asking how to recover the
SIDs during a reinstall. Thanks for the info. I am sure I will need it in
the future.
From: "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com>
Subject: Re: start over
Well, before you have that solution bronzed....don't.
It's not entirely that easy because the SAM isn't the entire story. The
registry is populated with SIDs, the Exchange DIR has SIDs, the Proxy Server
identifies users, the SBS Console has some awareness of workstations, setup
files and such. The user folders, user shares, distributed network user's
identities are somewhat addressed, but you don't have a complete answer just
with the SAM after the balance of the system is in. It's not like replacing
the SAM after the installation solves your problems if these are already
created, or that you simply create them again from scratch. Even if you do
the "replace the SAM after the first Windows boot" on the NT install, you
still have a bloody mess that most anyone would find too obtuse, time
consuming and impractical to do. When you look at the end game on this
approach, after you deconstruct all the elements involved, you probably
decide it was easier to use Roaming Profiles, a BDC, or restore from known
good backup. Better yet, upgrade to SBS 2K, establish another DC, then
fogetaboudit as an issue with no good answer. SBS 2K removes this nail in
the foot for good.
Subject: Re: start over
From: "Hollis D. Paul"
Well, I had wondered about the difference between SAM and SID. When you say
that "SBS 2K removes this nail in the foot for good", what does that mean
with respect to a new install not using the previous user profiles?
From: "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com>
Subject: Re: start over
Date: Wed, 13 Jun 2001 10:26:57 -0500
Newsgroups: microsoft.public.backoffice.smallbiz
Well, the short story answer is that the SAM is the unique database of
domain identities for Users and Machines. When you build a domain controller
from scratch, it's no different than building any other NT Server or
workstation (or W2K for that matter) in that a local SAM is created. The
difference is that when you identify that you want a new DC to be the PDC in
NT, or the first DC in a domain in W2K (essentially the same concept), you
are saying to the server "establish yourself as the first domain controller,
therefore the SAM you have now becomes de facto the SAM for the domain."
Now that you have a PDC or first DC in W2K, the SAM on this server is the
one that all future DCs added to the domain will also use. As a result,
every new server you install into this domain, when you say "make this
server a DC as well", you are instructing the machine to contact the PDC or
root DC or another DC with authority to join a new DC to the domain and the
end result is that this new DC will obtain a "replicated" copy of the
current SAM for the DC. Following this process, both the original DC and the
new DC each have a synchronized copy of the very same SAM.
This is all to explain the background of what the domain SAM is about. Now,
compare this with when you add either an NT/w2K workstation or an NT/W2K
member server.....all of these still have a local SAM established when they
are built. Their local SAM tracks local accounts to that machine, yet as
member servers in the domain, the Domain SAM accounts are recognized by this
machine providing the option to use Domain accounts in accessing local
resources that are shared. In other words, when a user attempts to access
the local NT/W2k member server or workstation's shared resources, this
server/workstation checks to see if the user attempting to access the share
is in either the Domain SAM (technically it is more like a request to a
Domain Controller to authenticate the user and determine if this user is a
known user with valid credentials to access the shared resource) or in fact
a user known to be matching a local user in the local SAM.
What I'm trying to identify and illustrate here is that the behavior of a
Domain SAM is essentially identical to that of a Local SAM, the difference
is that the Domain SAM is shared and synchronized among all DCs, and
recognized by all domain members in assigning permissions to local shares.
What distinguishes all the local SAM accountss on all the member servers and
workstations as compared to the Domain SAM based account is what is called
the RID (Relative Identifier). The RID portion of a SID is the part that
identifies what "SAM" that account is in. Therefore, technically, the SID is
a combination of information that indicated the RID to tell what SAM the
account is in, and the balance of the SID is the part that uniquely
identifies that user within the SAM in question. The result of this SID
having a RID and user ID portion means that all accounts in all SAMs can be
ensured to be unique. When you talk about a SID being unique, what you are
really pointing out is that there is an indicate that it comes from a
specific SAM, and you can tell the unique user from that SAM as well.
Phew!! So much background.
Now, summarizing this to this point, you now know that all NT/W2K stations
have a SAM, the contents of the SAM is the SIDs for all users created in
that SAM, there's also machine accounts to uniquely identify machines that
are members of the domain, and all accounts in a SAM have RID to uniquely
identify the SAM itself from which these accounts originate. You also know
that all the SAMs on all NT/W2K workstations are unique created with one
exception: the exception is when you add a DC (Domain Controller) to an
existing domain. Adding a DC forces the new DC to inherit the SAM it will
have as a replicant of the existing Domain SAM. In addition, the new DC
also inherits the trust associations that the Domain itself has authorized
to establish with other Domains. Okay, so now I have just mentioned the
idea of Trusts for the first time.
Trust is what enables you to make two machines accept authentication from a
different SAM than their own. When you join a workstation to a domain, you
are essentially saying "hey, there's this domain out here with DC and you
should allow this DC to tell you who's okay to logon or not....trust them."
Compare that to having two non-trusting domains, you have a conversation
that is like:
User: "Knock knock, I want to access your resources"
DC: "Who are you....give me your SID (full information including RID)"
User: "Okay, here's my SID (including RID)"
DC: "I see by your RID that you are not in my domain, and I don't know the
DC for this RID. Goodbye"
If this conversation is going on with a user trying to access a local
workstation or member server, the conversation would repeat with the local
SAM and access control to determine if the RID is in fact a local account.
If it's not, the query is denied and the access is denied.
Now, what does this have to do with SBS recovery and SBS 2K changes?
The design of SBS 4.x was that the only way to install SBS was to install
the SBS software from scratch on a new computer. That means that the SBS
installation would create the SAM as part of the installation and force this
computer to create a new one, not accept an existing one that is already
there. The result is that you can't recovery an SBS domain using a BDC
because you can't install the SBS application on an existing BDC that was
not created by installing from scratch as an SBS. In other words, it didn't
matter to SBS 4.x that you already have the SAM of an SBS server (that
died), what matter is that the SBS setup was looking specifically for the
fingerprints to identify that this actually is an SBS server itself, and
that it's just continuing from the earlier part of the SBS installation
during which it had created the SAM from scratch. That's the hitch.
With SBS 4.x there was no legal way to make an existing SAM on an existing
NT server become the platform on which you would install the balance of the
SBS product suite.....it just refused to do it. Given that you couldn't
install on an existing SAM (the one that has all the workstation accounts,
all the users accounts, and all the profiles that are tied to the use of
those SIDs containing the original RID from the original SBS), you were
forced to replace the SAM with a brand new unique one in the process of
scratch installing the SBS. The bottom line was that a BDC would preserver
the SAM, but it did not preserve the ability to promote the BDC to a PDC and
then install SBS onto that machine effectively upgrading it to include all
the SBS suite products.
SBS 2K does this.
SBS 2K setup says, "I could care less where the existing SAM on this machine
came from:
If this is a raw drive or one without an NT Server installation, I'm
installing W2K, creating a SAM, calling that the Domain account database,
then installing the SBS application suite.
If this is a standalone NT Server, I'm installing W2K as an upgrade, using
the existing SAM as my basis of the new domain SAM, then moving into the DC
promo to make this the root of the domain.
If this is a W2K standalone server, I'm promoting it to a DC, using the
existing SAM as my new domain SAM, moving from there.
If this is a W2K DC, I'm first looking to see if it has other DCs in the
domain, chatting with all of them to let them know the new rules I'm going
to impose about not trusting other domains. If other trusts are established,
I'm dumping the installation until those trust are broken. (Actually, any
trust, even from an NT domain upgrade hits this wall). If I find no other
DCs, no trusts, we jump to the conversion to AD if there isn't one already.
If there is an AD already, then I'm looking to see if there's Exchange on
this box or in the domain on another DC. If the Exchange is on another
machine....we aren't going to proceed. If there's no Exchange, or if it's
on this box, then we keep going.
If you follow the pattern I'm showing, essentially SBS 2K doesn't care where
a SAM originated. SBS 2K is only interested in making sure that the
restrictions of "no trusts" and keeping the AD with Exchange and W2K
directory services all on the SBS is honored. It needs to notify all DCs in
the domain about this rule, take over as the root server with various
responsibilities that implies. What it means that if you have a W2K DC, at
anytime you ever need to, if your original SBS 2K dies, you can preserve
everything.
When the SBS 2K dies, you go to your other DC and instruct it to "seize" the
domain primary role responsibilities. In doing this, your old DC can never
come back online. However, what you now have is a DC with the exact same
SAM
as before, and SBS 2K setup is going to be perfectly happy to install now
ontop of this DC without an argument. You can now install all the SBS
applications, recover your Exchange database from backup, synchronize the
information.....and now you have your SBS domain working on a new, totally
different server, but you have exactly the same SAM because this was in fact
a DC in the old domain.....and SBS 2K didn't require you to chuck the SAM in
order to install the SBS applications.
While it's still possible for you to loose some domain related information
in the loss of a root server in the domain, you are not talking about losing
the entire domain, nor are you talking about causing havoc across every
workstation with SIDs no longer being honored.
What remains true is this: You will always prefer to recover an SBS from a
previous backup. If you must migrate to new hardware, it's possible to
preserve everything with a planned migration using a DC promotion on a new
server....you just need to preserve all the domain information as required.
Once you migrate, you will have the very same arrangement as before, just a
new server. You will likely find it convenient to change the server name in
the course of doing a migration to preserve the UNC name paths, but I
digress. If you suffer a fatal death of your SBS 2K, but you have a DC, you
do now have the ability to pull the domain together on that DC, restore all
SBS functionality, and not require a scratch install from bare metal to get
there.
In a sentence: SBS 4.x disallowed upgrading an existing SAM on an existing
server in order to install the SBS suite, SBS 2K removes this restriction
and allows any NT/W2K Server to suffice as the starting point of an SBS 2K
server domain.
Subject: Re: start over
From: "Hollis D. Paul"
Let me ask if you think the following Mad Hatter scheme will work.
Basic constraint. I am using the Trios board to give me three distinct boot disks.
Trios1 has my existing "production" SBS4.5 server with existing users.
Step 1 -- create an NT server as member server, on dual boot of an existing workstation. Promote it to BDC, and let the SAM propagate to
it.
Step 2 -- Switch the server to Trios2. Promote the BDC workstation to PDC.
Step 3 -- Create a NT server as member on Trios 2. Promote it to BDC, and let the SAM propagate to it. Reboot the workstation to a local user
profile.
Step 4 -- Upgrade Trios2 to SBS2000 with the same SAM and users as Trios1.
Goal 1 -- The workstations will now be able to connect to either server--Trios1 or Trios2--without having to identify itself to the
network.
Goal 2 -- Replicate Exchange data through this chain also.
Is either goal attainable?
From: "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com>
Subject: Re: start over
I'm not going to leave any impression that I recommend what you are trying
to do. I do not recommend your idea at all, wouldn't do it myself, it's
pure academic nonsense from my perspective. Amusing conversation over a
beer. If you want duplicate machines....clone them. Messing with moving SAMs
like this is completely unpredictable other than at the developer level
(like Veritas).
From: "Jeff Middleton [SBS-MVP]" <jeff@cfisolutions.com>
Subject: Re: start over
I guess this has as much to do with your love of exploration and risk in an
adventure.
If you have a small LAN, it's just not a big deal to use Local Accounts on
the workstations that have the same username and password in each of the
"domain" configurations. In this way, the user appears to have transparent
access no matter which domain is currently active.
As much as anything, the problem with having identical domain SAMs all in
parallel is that if you don't have the entire concept of SIDs and security
totally in you mind while blindfolded, you will find yourself in scenarios
that leave you totally baffled. In essence, you outsmart yourself with a
situation that you aren't sure if it's because of your "concept", or
something else.
I generally maintain a number of Server installed drives in the office, but
not to run my office, only as testbeds. My office runs from the one domain,
an SBS and it's treated as the only domain that will ever be there. On
occasion, I may pull a copy of the old SBS 4.5 off the shelf, essentially
the original from which I cloned to get the upgraded version that is running
the domain now, but I wouldn't put that online in my network, only on an
independent LAN arrangement.
Hollis D. Paul [MVP - Outlook]
> If you have a small LAN, it's just not a big deal to use Local Accounts on
> the workstations that have the same username and password in each of the
> "domain" configurations. In this way, the user appears to have transparent
> access no matter which domain is currently active.
>
This is what is not working for me. Every time I want to logon to a server
account, I have to go through the "Identify yourself to the Network" process
if the server isn't the last one I so identified with. What am I missing
here? If I have a local account of OBTS\Hollis, and OUTLOOKCONSULT\Dwight,
when I change the server from domain OBTS to domain OUTLOOKCONSULT,
shouldn't I be able to log on with OUTLOOKCONSULT\Dwight without doing a
"Identify yourself on the Network" bit?
From: "Steve Foster" <steve.foster@picamar.co.uk>
Subject: Re: start over
Date: Thu, 21 Jun 2001 00:51:54 +0100
Newsgroups: microsoft.public.backoffice.smallbiz
The trick that Jeff's suggesting is to have LOCAL\Paul, THIS\Paul, THAT\Paul
and OTHER\Paul all with the same password. Then you *always* log on to your
pc's local account. Any time it tries to connect to a network resource, it
will automatically try "Paul" with your password. As there will be a "Paul"
account in every domain, it works. I use this approach with my clients & I
never have to reconfigure my 2k pro laptop.
The light finally dawns.
Hollis
