Is every user a member of Users?

[Herb Martin]

I am not so sure as to how much trouble in the life of the software
result from living with bad maning conventions as compared to
having new/appropriate ones (for a time) co-exist with the ones
that are being aged out.

The ambiguity you mention on primary DNS zones, the ones that
are standard primary and the ones that are AD integrated has always
existed. I struggled with this very thing when writing Windows
2000 DNS in late 1999, eventually deciding on the tactic used just
now. If it is SOA it is primary - whether AD integrated or not, and
if not then use the "std" adjective to indicate old-school, bind type
semantics.

RE: "If it is SOA it is primary" -- What do you mean specifically
by this phrase?

(I have corrected similar terminology in the past, so I would
like to know what that means before agreeing or disagreeing.)

All DNS servers that hold the zone have an SOA record and
are authoritative for the zone (ok, ignoring Stub zones for now.)

Sometimes I am tempted to distinguish the "special" principals
based on whether they, like Authenticated Users, cause an addition
to the user token, or whether they really are only used on the objects
being secured where they are interpreted with "special handling".
However, that is just too deep for practical, daily use.

Yes, it would help no one except system programmers who
really have no problem with the distinctions to begin with.

Oh, and speaking of pet peeves, my newest, as of today is the
"Malicious Software" Removal Tool, or was that the Malicious
"Software Removal" Tool ??

You probably would get a kick out of noticing the
breakdown (pun intended) of the following profession:

psycho-the-rapist

In future you will likely see me using the term dynamic and/or
synonomously automatic for the groups of type we have here
discussed.

I don't usually, even though I invented the terms because
then I must explain the standard Microsoft terminology too.

Generally when teaching about those I do mention these
names (dynamic or automatic) would have been better
choices.

It is meaningful, and distinguishes well the category
from what I have terms a (normal, custom or not) group.

Yes, many times just mentioning the better name choices
is also someone needs to latch onto the correct idea and
accept the clumsy name as-is.

For SiteLinkBridge(Groups) and Superscope(Groups)
I try to get everyone to ALWAYS append the word
Groups (or Grouping etc) to the name so as to remember
precisely what they do.

 

[Roger Abell]

RE: "If it is SOA it is primary" -- What do you mean specifically
by this phrase?

If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.
Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

(I have corrected similar terminology in the past, so I would
like to know what that means before agreeing or disagreeing.)

All DNS servers that hold the zone have an SOA record and
are authoritative for the zone (ok, ignoring Stub zones for now.)

You may be thinking on NS records here . . .

Yes, it would help no one except system programmers who
really have no problem with the distinctions to begin with.


You probably would get a kick out of noticing the
breakdown (pun intended) of the following profession:

psycho-the-rapist

all these years and I have managed to not see that one . . .

 

[Herb Martin]

If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

No, that is just wrong -- all secondaries hold a copy of
the SOA. This is part of the mistaken terminology (and
just an odd way of saying it) that I try to correct.

You know this if you think about your own secondaries
a momemt since all of them have that SOA record --
which like all other records on the secondary is not
editable.

In BIND, or any traditional DNS you also know that the
the "zone transfer" is a file transfer of the entire zone file,
including the SOA records which functions as the HEADER
record of the zone.

I see the problem below so keep reading please...

Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.

It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.

Traditionally the SOA record could only list one
"Primary server" because there was only one copy
of the replicated SOA record -- the same on all
authoritative servers.

Today, each DC may have an editable copy/version
and the option arose to suppress the replication of that
specific field even though other elements must be
replicated (responsible person, serial number, etc.)
to maintain the zone integrity.

There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".

 

[Roger Abell]

<quote>
the zone holds an SOA record for the DNS server
</quote>
"for the DNS server"
<quote>
Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.
</quote>
No, I was NOT confusing them.
I was explicitly stating the they are the same
when the zone is primary.
<quote>
There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".
</quote>
which is exactly the effect of the server named in the
SOA being the server the zone copy is hosted on,
i.e.
"the zone holds an SOA record for the DNS server"

and, as an aside
<quote>
It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.
</quote>
Then they need to translate the S of SOA meaningfully,
and to understand that they are thinking of NS records.
--
Roger

If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

No, that is just wrong -- all secondaries hold a copy of
the SOA. This is part of the mistaken terminology (and
just an odd way of saying it) that I try to correct.

You know this if you think about your own secondaries
a momemt since all of them have that SOA record --
which like all other records on the secondary is not
editable.

In BIND, or any traditional DNS you also know that the
the "zone transfer" is a file transfer of the entire zone file,
including the SOA records which functions as the HEADER
record of the zone.

I see the problem below so keep reading please...

Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.

It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.

Traditionally the SOA record could only list one
"Primary server" because there was only one copy
of the replicated SOA record -- the same on all
authoritative servers.

Today, each DC may have an editable copy/version
and the option arose to suppress the replication of that
specific field even though other elements must be
replicated (responsible person, serial number, etc.)
to maintain the zone integrity.

There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".

 

[Roger Abell]

Herb,

As an afterthough, I believe I see the source of our
linguistic confusion.
To me the SOA RR names the SOA.
So, saying that the SOA is the DNS server holding the zone
or

If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

is absolutely correct and precise, as

If the zone holds an SOA record for the DNS server

says, on the DNS server concerned, if the SOA RR names
that same DNS server as SOA

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

No, that is just wrong -- all secondaries hold a copy of
the SOA. This is part of the mistaken terminology (and
just an odd way of saying it) that I try to correct.

You know this if you think about your own secondaries
a momemt since all of them have that SOA record --
which like all other records on the secondary is not
editable.

In BIND, or any traditional DNS you also know that the
the "zone transfer" is a file transfer of the entire zone file,
including the SOA records which functions as the HEADER
record of the zone.

I see the problem below so keep reading please...

Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.

It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.

Traditionally the SOA record could only list one
"Primary server" because there was only one copy
of the replicated SOA record -- the same on all
authoritative servers.

Today, each DC may have an editable copy/version
and the option arose to suppress the replication of that
specific field even though other elements must be
replicated (responsible person, serial number, etc.)
to maintain the zone integrity.

There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".

 

[Les Desser]

Once more, if you do not let INTERACTIVE and/or Authenticated Users be
a member of Users, then removing an account from the Users group does
in fact stop that account from being a member of Users. If INTERACTIVE
is a member of Users, then as soon as an account has logged in locally
INTERACTIVE is replaced by that account, making the account a member of
Users. Similarly with Authenticated Users, except that as soon as an
account has authenticated it becomes a member of Authenticated Users,
and hence of Users. You can remove these from Users if you do not want
this behavior.

I think I will take you up on that suggestion the next time I want to
secure a PC in similar circumstances. I see from an other of your
replies that its removal can have repercussions on Guests but that is of
no concern.

It is simple when you know how!

(I still think it is wrong for MS to set , by default, BOTH a user
explicitly into Users and INTERACTIVE/Authenticated also into Users - do
one or the other but not both. Having said it many times in this thread
and been outvoted, I will now stop <bg>)

PS - just been reading an other of your replies, so maybe not completely
outvoted. You wrote:-

 

[Les Desser]

They are called the SIDs.

[Snip details]

Thanks. I have seen SIDs mentioned but need to read more

Not necessarily.

[....]

Thanks for your support.

. . . and if they do not, just remember the link www.reskits.com

Duly noted. Thanks again.

 

[Herb Martin]

No, I was NOT confusing them.

I was explicitly stating the they are the same
when the zone is primary.

Well, there is no way that only the Primary, and
not secondaries, has an SOA record.

The SOA is about the zone -- and the Secondaries
have a copy of this record.

That is mentions the Primary doesn't mean they
don't HOLD a copy.

--
Herb Martin

<quote>
the zone holds an SOA record for the DNS server
</quote>
"for the DNS server"
<quote>
Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.
</quote>
No, I was NOT confusing them.
I was explicitly stating the they are the same
when the zone is primary.
<quote>
There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".
</quote>
which is exactly the effect of the server named in the
SOA being the server the zone copy is hosted on,
i.e.
"the zone holds an SOA record for the DNS server"

and, as an aside
<quote>
It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.
</quote>
Then they need to translate the S of SOA meaningfully,
and to understand that they are thinking of NS records.
--
Roger

RE: "If it is SOA it is primary" -- What do you mean specifically
by this phrase?


If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

No, that is just wrong -- all secondaries hold a copy of
the SOA. This is part of the mistaken terminology (and
just an odd way of saying it) that I try to correct.

You know this if you think about your own secondaries
a momemt since all of them have that SOA record --
which like all other records on the secondary is not
editable.

In BIND, or any traditional DNS you also know that the
the "zone transfer" is a file transfer of the entire zone file,
including the SOA records which functions as the HEADER
record of the zone.

I see the problem below so keep reading please...

Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.

It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.

Traditionally the SOA record could only list one
"Primary server" because there was only one copy
of the replicated SOA record -- the same on all
authoritative servers.

Today, each DC may have an editable copy/version
and the option arose to suppress the replication of that
specific field even though other elements must be
replicated (responsible person, serial number, etc.)
to maintain the zone integrity.

There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".

 

[Roger Abell]

It just seems to me now that you are confusing the
SOA with the SOA RR
All copies of the zone hold the SOA RR
Only on a primary does the SOA RR name that
DNS server as SOA
In Bindish DNS this happens on only one DNS server
whereas in MS AD integrated zones this happens on
all DCs where the zone is held AD integrated.
In all cases the zone is primary because the SOA
that is indicated in the SOA RR is the DNS server.
--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

No, I was NOT confusing them.
I was explicitly stating the they are the same
when the zone is primary.

Well, there is no way that only the Primary, and
not secondaries, has an SOA record.

The SOA is about the zone -- and the Secondaries
have a copy of this record.

That is mentions the Primary doesn't mean they
don't HOLD a copy.

--
Herb Martin

<quote>
the zone holds an SOA record for the DNS server
</quote>
"for the DNS server"
<quote>
Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.
</quote>
No, I was NOT confusing them.
I was explicitly stating the they are the same
when the zone is primary.
<quote>
There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".
</quote>
which is exactly the effect of the server named in the
SOA being the server the zone copy is hosted on,
i.e.
"the zone holds an SOA record for the DNS server"

and, as an aside
<quote>
It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.
</quote>
Then they need to translate the S of SOA meaningfully,
and to understand that they are thinking of NS records.
--
Roger

RE: "If it is SOA it is primary" -- What do you mean specifically
by this phrase?


If the zone holds an SOA record for the DNS server, then it is
primary on that DNS server. If not, it is not, and so is secondary.

No, that is just wrong -- all secondaries hold a copy of
the SOA. This is part of the mistaken terminology (and
just an odd way of saying it) that I try to correct.

You know this if you think about your own secondaries
a momemt since all of them have that SOA record --
which like all other records on the secondary is not
editable.

In BIND, or any traditional DNS you also know that the
the "zone transfer" is a file transfer of the entire zone file,
including the SOA records which functions as the HEADER
record of the zone.

I see the problem below so keep reading please...

Now, it turns out that the RFC allows for only one SOA and so
with AD integrated DNS zone one will see that the SOA resource
record is different on each DC where it is hosted as an AD
integrated primary zone. But, if a zone is in the DNS on a DC
or otherwise, and that server is not named in SOA resource record
in the zone data, then it is not primary (i.e. is secondary).

Ok, you are confusing "named in [the] SOA" [as primary]
with "holds" the SOA record itself.

It's a poor distinction in any case since so many people are
already confused about SOA records in general (or know
nothing about them) and because they then extrapolate this
confusion to claim that Secondaries are (incorrectly) not
authoritative.

Traditionally the SOA record could only list one
"Primary server" because there was only one copy
of the replicated SOA record -- the same on all
authoritative servers.

Today, each DC may have an editable copy/version
and the option arose to suppress the replication of that
specific field even though other elements must be
replicated (responsible person, serial number, etc.)
to maintain the zone integrity.

There is a much simpler way, and that is if it the SOA
"editable" on that server it is one of the "set of Primary
servers".

 

[Herb Martin]

It just seems to me now that you are confusing the
SOA with the SOA RR

Of course I am talking abou the SOA record.

What distinction are you making?

 

[Roger Abell]

Of course I am talking abou the SOA record.

What distinction are you making?

The distinction should be visible in the above quote
that you left in the post.
You originally asked

RE: "If it is SOA it is primary" -- What do you mean specifically
by this phrase?

Again, SOA is indicated in SOA RR

 

[Herb Martin]

The distinction should be visible in the above quote

that you left in the post.
You originally asked
Again, SOA is indicated in SOA RR

No, that's wrong and even it it weren't it is just
too confusing to say such, as the field in the SOA
record is not known as "SOA" but rather "source host"
host in traditional zone files and "Primary Server"
in the Microsoft GUI.

Among those who do DNS, "SOA" is a synonym
for the SOA record.

There is no equation between the source host and
the record in which it is contained.

You will just confuse people with such terminology.

Which were precisely the type of misuse of terminology
we were both bemoaning that got us on this topic.

 

[Roger Abell]

I think we will just have to beg to differ on this one Herb.
When looking at an instance of a zone on some DNS server
and asking "is this zone primary" one may do as I have said,
look at the SOA RR and see if it names that server.
If so it is SOA, or "source host" whatever you should choose
as your term.
I think what we are into here is the sort of ambiguity that results
where one asks "what makes a DNS server authoritative for a
given zone". The normal answer is that it is named as NS in
an NS RR. However, if you read the RFCs the later do use
this, but the earlier only say the DNS server is authoritative
(for a zone) if it holds the data (of the zone).
I find no confusion in calling a host that servers as the source
of authority for a zone the SOA, and noting that it is named in
the SOA RR (given AD integration, one must qualify, in the
SOA RR in its instance of the zone).
Similarly I find no confusion in calling a host that is authoritative
for a zone an NS of the zone because it is so named by an NS RR.
I do however need to qualify this as so-called "hidden" name
servers will not have an NS RR, but can be termed authoritative
under the original statement in the RFC (which AFAIK has not
been specifically superceded) because it holds the zone data.