XP OEM

J

Jetro

Domain accounts don't have duplicate SIDs. Period.

I never ill-advised anyone. If someone is so dumb or desperate to get advice
without further research or understanding the details this is not my
problem.

Just curious why you're not at liberty to go into details but take a risk to
advise and oppose. I don't think a bracketed abbreviation can be enough.
 
J

Jetro

No wonder you are surprised. Real life and fairytales differ sometimes and
any theory without experience is dead. Try again to find an example when
local SID is involved in domain environment.
 
M

Mike Brannigan [MSFT]

Jetro said:
Domain accounts don't have duplicate SIDs. Period.

I never said they did.
I never ill-advised anyone. If someone is so dumb or desperate to get
advice
without further research or understanding the details this is not my
problem.

You have advised the posters on this thread that it is OK to allow machines
with duplicate SIDs to join and participate in domains. - This is not
correct - you should never use any machine in any environment with a
duplicate SID period.
Just curious why you're not at liberty to go into details but take a risk
to
advise and oppose. I don't think a bracketed abbreviation can be enough.

I am not at liberty to discuss specific technical or implementation details
of our products in a public forum. It is enough to say that you should not
use machine with duplicate SIDs.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups
 
D

Daniel Sinclair

Well I am surprised, yes. But as for why you probably shouldn't do this,
didn't I just give three? Or can you illustrate that there isn't a security
risk in SID sharing.

I also feel that its somewhat irresponsible to promote this activity on the
list against Microsoft best practice because even it you can get it to work
now you can't say for sure that this won't suddenly fail one day when a
service pack is applied and bring a domain to its knees. You'd then be on
shaky ground with respect to support.
 
J

Jetro

Daniel,

You can't oppose. Take two clones, crossover cable, create APIPA network,
and you'd be surprised again.

With regard to sudden fails, it could happen with anyone at any time for any
reason. It could happen with you, me, BG, the whole Microsoft, the Internet
etc. OTOH, it could never happen.

I believe the last thing Microsoft would want is that kinda check the local
SIDs in a network and disable or restrict a functionality if duplicates were
found. Bug-2000 (a big lie also, BTW) will be a parody of those
consequences.
 
J

Jetro

Mike,

Please read inlines.
I never said they did.

I never said anything else.
You have advised the posters on this thread that it is OK to allow
machines
with duplicate SIDs to join and participate in domains. - This is not
correct - you should never use any machine in any environment with a
duplicate SID period.

See my first comment. Actually I said "During the time you can change...
local SIDs" so you misinterpret.
I am not at liberty to discuss specific technical or implementation
details
of our products in a public forum. It is enough to say that you should not
use machine with duplicate SIDs.

See my first comment.

Unfortunately this is not "enough to say" in a public technical forum
without any proof such as technical documentation. "Enough to say" argument
is the last one when you argue with your dumb kids only and you really have
no other arguments.
 
M

Mike Brannigan [MSFT]

Jetro said:
Unfortunately this is not "enough to say" in a public technical forum
without any proof such as technical documentation. "Enough to say"
argument
is the last one when you argue with your dumb kids only and you really
have
no other arguments.

Jetro,

When it comes to the internal operation of Windows (which is not subject to
public disclosure) and our intellectual property - it is entirely sufficient
for me to tell that you should not ever use machines with duplicate SIDs in
a public forum.


To use your analogy of kids arguing - lets just take that a step further to
parent to child.
It is enough to say to children who either would not understand or who
should not be exposed to the details of something that this is the fact and
you as the parent are not required to provide any further evidence.
This is to in no way downplay you technical capabilities but when it comes
to issues related to the internals of our products sometime we have to just
make a statement of fact and leave it at that.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups
 
J

Jetro

Mike,

So there is no documented evidence?

Microsoft does not provide support for computers that have been installed by
duplicating fully installed copies of Windows - this is her unconditional
right, as I've said, but who cares? If someone can determine that the core
of her problems is a duplicate SID then this someone doesn't need Microsoft
support :blush:)

Here is a theoretical cause when duplicate SIDs can be allocated in domain
environment.

Each DC maintains a pool of relative IDs that is used to create SIDs. When
80% of the relative ID pool is consumed, the DC requests a new pool of
relative identifiers from the RID operations master. This ensures that the
same pool of relative IDs is never allocated to different DCs, and prevents
the allocation of duplicate SIDs. However, because it is possible (but rare)
for a duplicate relative ID pool to be allocated, you need to identify those
accounts that have been issued duplicate SIDs to prevent incorrect security
from being applied.

Duplicate relative ID pools can occur if the administrator seizes the RID
master role while the original relative ID master is operational but
temporarily disconnected from the network. In typical practice, after one
replication cycle, the RID master role is assumed by just one DC. However,
before the role ownership is resolved, two different DCs might each request
a new relative ID pool and be allocated the same relative ID pool.

This is the only particular situation when an Admin should use the
ntdsutil.exe tool, check, and cleanup duplicate SIDs if exist.
 
M

Mike Brannigan [MSFT]

Jetro said:
Mike,

So there is no documented evidence?

Our statement of not using any machine with a duplicate SID is sufficient.
Microsoft does not provide support for computers that have been installed
by
duplicating fully installed copies of Windows - this is her unconditional
right, as I've said, but who cares? If someone can determine that the core
of her problems is a duplicate SID then this someone doesn't need
Microsoft
support :blush:)

I fail to see your point - we make a simple direct statement and you still
wish to argue the merits of it.
If you wish to ignore our stated recommendations the that as you say is your
right to do so - but you are making potential problems for you and your
customers now and in the future.
Here is a theoretical cause when duplicate SIDs can be allocated in domain
environment.
<snipped as not relevant>

It is not about Domain SID duplication - the simple fact as I have stated
over and over again - you should never under any circumstances use machine
that have been incorrectly built that has resulted in duplicate local
machine SIDs between those machines.


--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups
 
D

Daniel Sinclair

Jetro
You obviously have some good first hand knowledge of the successes of SID
sharing within a domain, hence your overly flippant first comment on this
thread. It is however the kind of statement that needs qualifing and I still
don't believe its something that should be promoted to perhaps novices
reading this list, especially when its strictly against the advice of the
manufacturer.

With regards to future failures I don't think its a matter of introducing
enforced constraints for no reason. Microsoft would be unlikely deliberately
dissalow duplicate SIDs for the sake of it. However, you probably already
know of the security issues with machines sharing duplicate SIDs, we know
they're also used to generate autoconfigured IP addresses (undocumented) and
I believe in other areas (eg. COM+) in configurations which you may not have
encountered on your site, so there may very well be others, now or in the
future. Its all down to the internal implementation of windows. What you
'observe' on Windows 2003 SP1 now may very well not be the same in SP2 or
Longhorn.

I think the bottom line is this: Since the manufacturer advises that you
don't duplicate SIDs they may have good reason, and possibly reasons that
they aren't at liberty to disclose which may involve future plans for using
the machine SID. This may be a new feature they decide to introduce in some
future version which would not work for all those users who had chosen to
implement their infrastructure against the manufacturers advice.

I fail to see how you can possibly argue with this point.

If you ill adivse users to take this route, are you suggesting that you
personally will be in a position to support them where Microsoft may not?
Are you offering to take liablity for the consequences? If not then you
shouldn't be promoting it blindly...period!

By all means do use your extensive knowledge of how domain SIDs are used,
and by all means share your valuable experience and stories of what you've
succeeded to do that is against either common knowledge or best practice, in
fact I and others on this list would welcome it since its something that MS
employees may not be at liberty to discuss for various reasons. But do
qualify your statements and don't make flippant, throwaway, unqualified
comments on this list that could be interpreted as directly by readers who
may take your advice without understanding the consequences and may find
themselves in an unwanted future position.
 
J

Jetro

There is your own statement in this thread only. If you can change an
appropriate MS KB article or EULA then do it and I stop my practice.
Everything else is irrelevant.
 
J

Jetro

Daniel,

Haven't I said in initial post "you can change... the local SIDs if you
would need it"? <shrug> Please do not misinterpret.

The manufacturer never advises that you don't duplicate SIDs. MS
*recommends* that you use a supported method to avoid compromising security.
How? An identical computer SID compromises security in Workgroup
environments, and removable media security can also be compromised in
networks with multiple identical computer SIDs.

MS states that it "does not provide support..." and I completely understand
and support that position. OTOH the policy as such can be quite inadequate.
For instance, you purchase a computer with XPHome preinstalled, wipe it off,
and install something else. On 365th day afternoon the box starts hanging up
and freezing. You check the components and find out the motherboard must be
replaced. You call the service and they tell you to use a QuickRestore CD
before you can get any invaluable help. Now you get stumbled - you got 20-30
GB of G-d-only-knows-what-applications and you got neither spare disk nor
up-to-date volume image in the middle of nowhere. Sadly, does anyone need
such support if the motherboard will be inevitably replaced? But this is a
manufacturer's support policy too.

I'm still insisting that no-one should takes any suggestions without further
investigation or *a priori* unless you trust the source or get an order;
it's just a brain reload, a light at the end of the tunnel, unblocking...
You got your systems screwed up and this is your responsibility to fix it or
kill it, so bear it.

Good luck.
 
M

Mike Brannigan [MSFT]

Jetro,

I'm sorry but if you are not willing to expect the statement directly from a
subject matter expert on Windows and Active Directory then I'm not sure what
else we can do to help you.
Our statements are clear both here and in our own KB articles -
for example
http://support.microsoft.com/default.aspx?scid=kb;en-us;162001
and
http://support.microsoft.com/default.aspx?scid=kb;en-us;314828

Ignore this at your own risk (and at your clients too if you actually do
client facing work) but we have made our position plain and clear to you.


--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups
 
M

Mike Brannigan [MSFT]

Jetro said:
Daniel,

Haven't I said in initial post "you can change... the local SIDs if you
would need it"? <shrug> Please do not misinterpret.

The manufacturer never advises that you don't duplicate SIDs.

Yes we do - please see my other post. And I have also clearly stated this.
--

Regards,

Mike
--
Mike Brannigan [Microsoft]

This posting is provided "AS IS" with no warranties, and confers no
rights

Please note I cannot respond to e-mailed questions, please use these
newsgroups
 
J

Jetro

Mike,

Don't you think I never read these two and other articles. Change them and
clearly state that "A domain should never under any circumstances comprise
of the machines with duplicate local SID" and why, if you can. Again, I
accept that "MS doesn't provide support..." etc but you deliberately
misinterpret the articles or just don't understand the matter. Do they teach
you to lie in [MSFT]? Did your mother teach you to lie?

P.S. As I supposed, a "subject matter expert on Windows and Active
Directory" is your only "irrefutable argument". Wadda ya expect - that I
shoot or drown myself? To me it's another wording of "I'm not at liberty to
say but nevertheless talk". Thanks G-d, you don't argue in terms of MS
certification yet. Believe me, I've seen enough of self-proclaimed Windows
"genii" who didn't know the computing basics. Don't fall into the same trap
and never say publicly "I am an expert".
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top