|
Posted by Roger Abell [MVP] on January 27, 2007, 12:25 am
Please log in for more thread options >>
>> Why did you bother to include 4 about the built-in Administrator?
>
> I did not find a way to limit the login of the built in Administrator
> account to particular machines, which then creates a network based
> exposure.
>
Understood.
But I asked as I did not see how the fact (4) bears any relevance
upon your question (e.g. what mischief could a DA account bring
to the DC server config or to AD if uid/pwd became known, given
1 through 3 and no physical console access).
The inability to limit the domain's Administrator built-in to (a)
specific DC(s) does not create a needed network exposure, as
it is still logged into a DC (unless it is in DA and hence in all
Administrators groups when this nesting is left as in default).
>
>> Why did you not mention network login user rights?
>
> Well, remember the other thread I started recently. I discovered there
> is
> a misfeature (I would call it a bug) in the way Microsoft implements Deny
> privileges for network access. Instead of interpreting this in the
> sensible way to mean access by a computer that is not the local computer,
> over a network, they instead interpret this privilege to mean "Deny access
> to the SMB interface, even when that interface is used during a local
> login"
> Microsoft's entire group policy update and maintenance is based on SMB
> access to the GPO object files!! When you login locally, you apply group
> policy by reading in a file at:
>
> \my.domain.com\sysvol\......
>
> and if your account is in the Deny access over network user privilege,
> Microsoft locks the account out from group policy. So while I would
> very
> much like to add Domain Admins into the Deny access from network
> privilege,
> doing so isn't possible without breaking basic and very important
> functionality.
>
Yes, I do indeed recall our discovery thread on those issues,
and find it great that you have taken the pain to recap for the
NG archive/readership examples of the issues.
The reason I pointed out your omission of a clampdown on network
login rights is precisely because it means the a number of ways to
effect change to the DC servers' configs and to AD are left open.
So, due to this "bug" (of requiring network login for some essential
functionality that one does want DA accounts to have, ex. manage
GPOs, and that one does want to have imposed on DA accounts,
ex. subjected to GPOs, even though all the needed accesses are
local) one does not block the use of some APIs.
As I commented before, perhaps it is just an optimization of avoiding
code for a special case in the redirector, but this "bug", likely design
flaw, here creates major problems for your objective due to the choice
to leave DA with the network login user right. And, I agree, it certainly
seems all accesses needed to support the examples we ran upon can be
and should be (and likely always are) DC instance local (ex. not going
to sysvol on another DC) when the DA is logged on to the DC locally.
It is as if one could say, a demand for network login user right can be
satisfied by local login (not local login right, but actual login), then we
could prevent a group of APIs and not prevent DA from having or from
being subjected to some desired/essential features.
> Speaking of wish lists, I really wish I could define user privileges by a
> "NOT" operation against a group. For example: define the Deny login
> locally privilege as "NOT Domain Admins". This would mean any account
> that is not a Domain Admin doesn't login locally.
>
Agreed; and up you one . . .
I have long wanted complete set and boolen algebras available for
stating a criterion where today Windows allows a group, rather than
the desired ability to use a group expression (yes, some places would
have to remain allowing only a group singleton).
>
>> There are quite a few APIs that allow for providing username and
>> password (ldap binds, wmi, etc.) which, with what you have said
>> are still available.
>
> I have not tested, but in theory shouldn't each of these require a network
> login to authenticate the user and pass on his credentials? And if the
I cannot state for "each of these" as in "all of them". But yes, I know of
ones that do require network login (and hence the second question I asked).
> user has a login that is restricted to the domain controller itself, won't
> the attempt to get the kerberos credential remotely fail?
>
Again, there are APIs that manipulate the server or AD that do allow
one to specify a username and password. With the remote machine
being given these, it can perform a login. This is independent from
the account in use to invoke the APIs. Also, notice that in this case
the prohibitions on delegation of or impersonation of a DA account
do not immediately come into play (i.e. at least not in the first step).
> I don't take for granted that Microsoft implemented any of this
> consistently
> or correctly, which is why I am asking the question in this thread. I
> want to learn about the documented holes just so I understand my
> exposures.
>
It is pretty hard to maintain consistent over even the 10.x years from
NT 4 release to now, and that only covers the time since the intro of
COM to date. We obviously have remoting techniques now unforeseen
or at least not fully specifiable back when COM started to grow usages.
Because I find your question highly interesting, and important, I had to
ask the second question, as denying network login is the large chuck in
factoring out ways DA credentials could be used to cause violence to
infrastructure, allowing better focus on the lesser chunks.
> I suppose there are hacker tools that would form the request anyway,
> without
> using any Microsoft software to do it. But without the credential
> attached
> I guess the request gets rejected on the DC, and at best you have a denial
Again, not a valid supposition here, or perhaps just an incorrect meaning on
"credential"; that is, for some instances of concern here, textual
presentation
of the credentials is sufficient. An initial Kerberos ticket exchange or
other
presentation of user token is not the only means; hence one does not gain as
much from limiting DAs to only log into DCs as you are thinking/wanting.
> of service attack. That I could surely live with. And as I pointed
> out
hmmm . . . not putting my finger on the DoS you had in mind, but can
think of some where availability of DA creds is irrelevant, needing
only the network access on the correct ports as domain user.
> in different threads, we have the DC properly firewalled, with fixed ports
> assigned to the four required RPCs (endpoint mapper, Netlogon, NTFRS, and
> NTDS), so we don't have any ports exposed that are not running Microsoft
> software.
And for this current objective, regrettably the RPC mapper is needed
as it forms a major route for APIs we cannot disallow via user rights.
As I pointed out in other threads, the design I would advocate is to
use custom groups (ex. for admin on sets of machines) and delegations
of well-defined rights for different admin/mgmt roles, and to keep DA
very tightly held and used only for its abilities with AD (and when not
covered otherwise via the delegations or custom group based broad
admin over members). It is problematic to attempt to constrain DA,
but it is possible to greatly reduce the need for DA usage. The extent
of DA usage however does not directly bear on the topic here, where
we assume that a DA username/password pair was compromised but
it might limit the probability of the compromise.
Roger
PS. Have you considered requiring smart card for DA/EA/SA login?
>
>> > Here's a good trivia question for AD and security experts.
>> >
>> > Let's assume that you have locked down the domain controller in the
>> > following ways:
>> >
>> > 1) The domain admin accounts are marked as sensitive and cannot be
>> > delegated.
>> >
>> > 2) The domain admin accounts are marked to only allow login to the
> domain
>> > controllers
>> >
>> > 3) The domain admin accounts are marked to not allow login by terminal
>> > services
>> >
>> > 4) The default administrator account is disabled
>> >
>> > If you have done all of the above, and someone had the username and
>> > password
>> > of one of your domain administrator accounts, but they did not have
>> > physical
>> > access to the console, what damage could they still do to your domain
>> > controller or your AD? Since they cannot login to any machine
>> > except
>> > the
>> > DC console, cannot be impersonated, and cannot access remotely by
> terminal
>> > services, I'm hoping that there won't be many more backdoors to cover.
>> >
>> > --
>> > Will
>
>
| 
XML Sitemap