|
Posted by Roger Abell [MVP] on January 14, 2007, 10:27 am
Please log in for more thread options
>> > 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.
>
> 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.
>
>
>> Authenticated DNS updates function via DNS server using impersonation
>> for authenticated LDAP with domain controller, after initial exchange by
>> DNS with requesting updater client, which IIRC is Kerberos based.
>> LDAP:// and GC://, Kerberos, DNS, etc. I think your chasing out this
>> list is example of what I was trying to suggest, that you look at
> whitelist
>> approach instead of needing to find and plug all (blacklist).
>> If account is allowed local login, not allow network login, on select
>> group of machines, then by and large you have only the unauthenticated
>> accesses or those authenticated by specific services (ex. backup agent)
>> that have their own listeners and implement their own authentication.
>
> Are there user privileges other than "Deny access to this computer from
> network" that you are referring to here?
>
> And I thought it was your point that you cannot restrict access by the
> above
> privilege on anything more than SMB activity (no protection on RPC, LDAP,
> DNS, Keberos, etc). So I don't understand how to *either* whitelist or
> blacklist any user against RPC, LDAP, DNS, Kerberos, etc, in a way that
> would allow the activity read/write locally but allow the activity only
> read-only by the network. If there is a way to do that, I would love to
> hear about it more.
>
>
>> > 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.
>
>
>> 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.
>
> 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. The latter means I need a different
> group of accounts to administer member servers than DCs, and maybe that's
> okay.
>
>
>> 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.
>
All very good points Will. It is my own opinion that the application
of Group Policy should never have depended on access to fileshares,
and if (as) so, then it should have been done in the machine credentials
for users policy application just as it is for computer policy application.
I totally agree that having user policy apply reliably is a very valued
part of the total Windows domain package. Prior to W2k release, no,
more correctly, prior to its rename from NT5 to W2k, we were told
that the implementation would be NetBios-free; thence direct hosting
on Tcp 445 came along, and then finally they seeming gave up on
ever removing the need for the NetBios ports.
I am still not seeing why you do not just configure the account that
are allowed admin on a DC to only be able to log into the DCs, or
perhaps the DCs plus designated administrative stations.
Is not the issue that you do not want those accounts administering
the DCs or AD unless they are logged in locally to them?
Roger
| 
XML Sitemap