|
Posted by Will on January 14, 2007, 12:46 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.
--
Will
| 
XML Sitemap