% So even if the Firewall were compromised, none of its accounts would be
% permitted to access the resources protected internally by the
% Administrative Domain security, and remember, neither the user ID or the
% password are transmitted across the network between the two.
%
"Uhm, what we mean is, that if your _PRIMARY NT DOMAIN CONTROLLER_
got compromised, your firewall would be useless......."
Yes, and that's also true if you are using an ACE Server, or Radius, or any
other authentication server for your firewall. So what's your point, that
its too easy to compromise a Windows NT Primary Domain Controller? I don't
happen to agree.
In any site that is already using NT for security of networked resources,
extending the security model to the firewall is logical, for them, if they
desire to focus their attention on a single authentication scheme. I see no
reason why this is not perfectly viable providing that their security
policy addresses it properly, as it would have to do with any source of
ACL's. It means, from an administrative perspective, that they fewer
sources of security audits to monitor, which can make detection easier. In
addition, management of a single set of accounts can streamline a security
policy, making its adoption, adherence, and proper usage more likely.
In my book, these are two of the most important issues relating to an
effective security policy.
Let me restate a premise:
I am not suggesting that an organization, whose security personnel are
already familiar with brand X UNIX, or brand Y firewall, dump their
equipment and go out and buy some Windows NT Firewall. I am suggesting that
there are a lot of organizations who are in the process of implementing a
firewall who do not have such personnel, but instead, have people who
already understand and/or manage Windows NT resources.
It does not make sense to say that the only way these organizations can
safely connect themselves to the Internet is through a UNIX flavored fir
ewall. As X.500 is more widely adopted, the need to provide a single user
administration database becomes more apparent. NT offers this capability
today, through the use of Exchange Server, which supports multiple name
spaces for a single account, single logon, bulk imports from other systems,
etc... As more Directory Structure vendors, like Banyan, write products to
the ODSI specification which allow them to integrate their naming systems
into NT, there will be even great adoption of NT as a centralized
authentication server. We already have Radius and TACACS support, and I
doubt that ACE is very far away.
NT cannot just be ignored, but if its unsafe for Enterprise Authentication,
let's not find that out after you've been tasked with implementing it.
Cheers,
Russ
|
|
