|
Posted by Roger Abell [MVP] on January 16, 2007, 2:27 am
Please log in for more thread options
just reviewing, adding a comment
>> > Regarding only restricting access to SMB resources, understood, but
>> > what
>> > other resources are of concern? I guess the most troublesome would be
>>
>> Anything that has bound a listener to a port.
>> Ex. How about your backup agents?
>
> Yes, but in our case we firewall the domain controller (what a lot of work
> that was to do and debug by the way!), so I can guarantee that nothing on
> any remote machine has access to any ports other than:
>
> DNS
> Kerberos
> LDAP
> LDAP GC
> NTP
> CIFS (Port 445 only...no 137, 138, or 139 on our network thanks)
> RPC Endpoint Mapper
> RPC (Netlogon)
> RPC (NTDS / DRS)
> RPC (FRS / NTFRS)
>
> We even locked down the RPC services on fixed ports, so there is no wide
> open window for any other RPC service than the ones listed above. It
> actually works. I probably left one or two off but the idea is clear.
> We
> aren't going to get hacked on the backup agent on port xyz, because no
> domain member server has access to the domain controller on that port.
> But
> what I am saying even after you do all this additional firewalling, and
> reveal only the bare essential ports of the DC, that you really don't
> protect yourself very much because a remote user with admin access can
> really nail you on most of these open ports.
>
from what you list as open it is obviously the rpc and/or ldap
mostly that a rogue/lifted admin could use to cause pain
> The only thing that makes a domain controller securable is to have no
> administrator accounts at all. You can't impersonate or use stolen
> credentials for what doesn't exist. But that's not a practical solution
> either.
>
Set your admin accounts as sensitive, cannot be impersonated, which
you should notice is not the default for new domain accounts.
Have you considered requiring smartcard login for these accounts?
. . .
>> > I guess controlling administrator remote access to those resources on a
>> > domain controller is just about impossible, because without those the
>> > administrator cannot login to the remote workstation and would not be
>> > able to use any application on the remote machine that requires
>> > browsing
>> > of domain based resources.
>>
>> Any why do you want them to be able to do that if you are, as your
>> history here clearly shows, concerned about effecting a well secured
>> deployment.
>
> Well, for example, if I pull up the local users list on a member server,
> it's quite possible that the users there will be domain entities in the
> local groups, so already I have RPC Netlogon, and some of these other
> services to just generate that list of domain entities and form the domain
> SIDs in a human-friendly format.
>
Any domain member can do that. They do not need to have admin at
the DC or AD level. The MS design of DAs being admins everywhere
leads people into using DA that way. This facilitates quickly deployed,
off-the-shelf small environments to need minimum adjustment to have
central, unified administrative management. This is however the wrong
way to use DA, that is, to use DA everywhere. DA (and EA) is key to
all, and all member management can be done with custom groups to
thread out categories of member admin to those needing them.
>
>> I am unclear as to a precise statement of your objective that
>> underlies this posting. What is it? I want to let DA log in on
>> machines m1, m2, ... mX (uncontrolled list), but when on those
>> I do not want them to be able to connect remotely to the DCs?
>> If they are not going to be managing aspects of AD that are
>> rarely adjusted or only difficultly delegated, then why are
>> they using a DA account? If they are to be not allowed access
>> to the DCs why are they using a DA account on the non-DC?
>
> For a forest with a single domain and single domain controller, I would
> like
> the administrator to be able to login and administer the domain and domain
> controller locally. I want to protect against network / remote
> administration of the domain information or domain controller.
>
As we were hashing through, if one can control where the account
can log in locally, then one rules out use of a number of management
interfaces except while on allowed machines. However, most all of
those management GUIs have funtionality that one can program up
with supplied credentials (i.e. local login not needed).
> For remote access of the domain controller or AD applications by the DC's
> Administrators or Domain Admins, I am happy if they have either read-only
> access, or are simply denied access.
You see, that sort of looses me.
If they are not using DC or AD admin privs, then they should not be
using the account. If the use of a DA is due to DA membership in
all member admin groups, one only needs to define the intended
admin accounts for the sets of members.
> The latter means I need a different
> group of accounts to administer member servers than DCs, and maybe that's
> okay.
>
Okay? It is pretty much a prereq if you want to step beyond the
off-the-shelf one-size-fits(abeit maybe not well).
>
>> That you can break GP application is true, as well as a host of other
>> things dependent on the access (DFS dereference if replica there,
>> login scripts, software install, etc.). Those however did not break
>> Windows per se, it is there and stable; you impaired features.
>
> That's a good point, but group policy is a very attractive part of the
> package we are buying into here, and I guess I don't want to accept
> breaking
> it quite so easily. At very least that would leave me with a
> configuration
> Microsoft wouldn't want to support.
>
> I wonder if it isn't just a bug that a local login to a DC breaks group
> policy when the user is in the "Deny access to this machine from the
> network" user privilege? In the big picture shouldn't the code that
> implements group policy be smart enough to know that when it goes to grab
> the group policy templates from:
>
> \mydomain.com\sysvol\....whatever-path\...
>
> that the "Deny access" privilege should only apply to a login that is not
> local? I can't honestly see much utility in their enforcing this
> privilege
> for a "network" reference to the local machine during a local login.
Nor can I. It appears that "network logon" is meaning something like
"redirector usage", that is used whether local or remote. If so then
this appears just an optimization (i.e. avoiding special case handling).
Many hear "Deny access to this machine from the network" and think
it means what it states, which it does not mean (just some of it). So
I guess this is inaccurate in a number of ways.
Roger
| 
XML Sitemap