Let me see if I can shed some light here.
1. In the scenario described, the Domain Controllers that the Firewall
can defer authentication to are inside the Firewall, so any attempts at
getting either between the Firewall and the DCs requires a breach in the
Firewall first. So if you're trying to get in between them to get a
password, why bother, you're already between them if you can see any of
the exchange so just go off and do whatever damage you're trying to
do...;-]
2. I'm not exactly sure how they've implemented this, but I'm aware of
two possibilities;
a) The first is to have the Firewall act as an "untrusted" domain
connected to the internal domains. This means that none of the accounts
established on the Firewall are valid on the internal domains. The
Firewall would then "trust" the internal domains. This doesn't confer
administrator status to the internal domain's administrators, but it
means that the Firewall could then send authentication requests to the
internal domain for validation. It would do this via an encrypted RPC
channel established at boot time between the Firewall and a domain
controller (not necessarily the Primary Domain Controller) for each of
the internal domains that it trusts. This encrypted channel is based on
a number of things, including an unknown password, a security
descriptor, a machine name, and the domain name. Unlike mere account
authentication, this method of authentication is not susceptible to the
limitations of normal accounts (which only require Lan Manager type
authentication).
This encrypted channel doesn't permit the Firewall access to the
internal domain's Security Access Manager (SAM), but instead simply
allows the Firewall to accept authentication requests and pass them
along to the internal domain for authentication. If authenticated, a
"nonce", a one time key is created identifying the authenticated user
(or object), and the list of access rights are returned to the Firewall
in the form of a set of keys. The Firewall would then compare the list
of keys with the key it created when it permitted the user (or a group
that the user is a member of) access to a particular resource (i.e. a
service, a port, whatever the Firewall wants to define rights for). If
the key exists in the set of keys returned for the user ID, then access
can be permitted, if not, then it is denied.
This could be used to do denial of service, but no more than any device
which uses a third party for authentication. If the Firewall is going to
authenticate against a third party, its has to pass the authentication
request on to another device, as is the case with a trusted domain.
Once again, to forge this you would somehow have to be able to place
packets on the network link between the Firewall's internal adapter and
the trusted NT server. Since this isn't a constantly listening two way
channel, just stuffing packets wouldn't be of any use. You would have to
get the Firewall to want to authenticate you, and then stuff the packets
in place of the packets its actually sending or receiving. Since the
channel is encrypted, and the whole process associated with a
time-limited key created between the Firewall and NT Server when the
Firewall booted, forging this would be quite a challenge.
b) I was also aware of some sort of HTTPS channel being used between the
Firewall and the NT Server to replace the encrypted channel used by the
trust relationship. This would allow Raptor more control over this
channel, and possibly more integrity with the communications from their
perspective (since its their's, and not MS). They could then provide a
service to be placed on a PDC to interact with the MS Login process to
handle the challenge and return a simple "Yes/No" response. Rather than
speculate too much about this, maybe Dale can tell us if this is so.
3. As Peter pointed out, you don't rely on a PDC to do authentication.
In an NT world, the PDC is the sole place where the user database can be
modified, but Backup Domain Controllers (BDCs) have complete copies of
the entire user database, and offer the ability to use them as a logon
source. They are capable of doing complete authentication including
returning the keys for all the groups, rights, etc... that the user has
access to. So if the PDC fell over, first of all, automatically another
BDC on the network (either on the same LAN or across a WAN link if its
part of the same domain) will assume the role of PDC and promote itself
to this role. It then becomes the sole location for the user database
modifications.
Now if Raptor has used method 2.b. above, then there is the possibility
that losing your PDC could render your Firewall inoperative (I'm sure it
would fail closed, or maybe just be unable to authenticate access and
therefore deny access to valid users), but the loss of a PDC in any NT
environment is no small occurrence, and if all it takes is to install a
service on the new PDC, this would probably not take very long to
arrange (i.e. there might be a small window of denial). If its using
method 2.a. above, then the change would be transparent to the Firewall.
4. John Betts proposed that the sniffed password on the Internal network
would be as valid as the real password, presumably using this sniffed
password to fool the Firewall into allowing you access to resources.
This is dreaming John...;-] The user ID and password combination are
first OWF encrypted, and then recombined and encrypted with either DES
or RSA, depending on what type of client you have. While its true that
the data that is stored in the SAM (and what is used to compare against
the encrypted user ID/password combination) could be recreated from the
OWF, the problem is that you have to somehow get the Firewall to issue
the authentication request and then stick your sniffed information into
the packets that it is sending to the NT box. If you don't do that, then
having the information doesn't serve you any purpose. In addition, the
information sent via the encrypted channel between the Firewall and the
NT box is sent in the clear (inside the encrypted channel), so your
sniffed information is not what is inside the encrypted channel.
In addition, these user ID's can't access the Firewall itself, but are
used as authentication for Firewall services, so no matter what you do
you could not use this information to log into the Firewall and change
permissions. The Firewall, in either case, is using its own, local, user
ID's for its own administration, not accounts from the Internal domain
(although you could probably enable this unless Raptor has specifically
denied that ability, in which case you would have to be careful about
the clients you used to administer the Firewall...that's assuming they
used this method to enable remote administration, and I have no
knowledge that they have done this...)
5. Paul asked, "what makes a PDC authentic?". Basically, in real simple
terms, there is a key in the encrypted registry that tells the NT box
that it is the PDC, and a different one that tells each BDC that they
are a BDC, and so on. This key can be changed by a user that has
Administrative rights on the box, but if they did change it, then they
would only have access to their local SAM, not the SAM on other machines
(unless their Administrator account was already the domain's
administrator account). So, yes, I can make any machine I want into a
PDC, and I can even make it the PDC of an existing domain. This will
only result in denial of service of any kind if I make a valid BDC of a
domain into the PDC of the same domain, since their SAMs, and therefore
the security keys, are the same. If I was to install a completely new
machine and just tell it that its the PDC of an existing domain, no
existing machine on the network would consider it as such. New machines
being added to the network might get confused, and possibly become
members of the forged domain, but this would be plainly obvious to a
reasonably knowledgeable NT administrator and be easily traceable.
As to failover due to router problems, these are an issue with NT. If we
assume model 2.a above, where there is a trust relationship, the loss of
the route to a valid DC for a domain which has been trusted will result
in the collapse of the trust. There is a timeout period, where the
Firewall would continue to attempt to reestablish the trust, but after
this period has completed, the trust is broken and would have to be
reestablished through administrator intervention. Because of the
distributed nature of domains, you could have valid DCs for a single
domain on multiple subnets, in which case, as long as one of these can
be reached the trust will persist. NT doesn't care which one of multiple
DCs for a domain it is connecting to.
Most recommended domain configurations will have at least one DC on each
network segment, physical or protocol, although more cost effective
solutions can be found if necessary. Since a DC could also be used as a
workstation, they can be transparently placed in many locations, albeit
with a higher level of risk.
The process of creating a valid BDC in an existing domain requires the
presence of the PDC, it cannot be done without it. As I said earlier,
you could forge the domain altogether by dropping the existing PDC (and
all its associated BDCs because one of them will immediately become PDC)
and creating a new PDC with the old domain name. However, if you did
this, the trust between the Firewall and the domain would be broken, as
you would not have the keys to validate the trust with the Firewall (its
more than just a password and domain name). By the way, the same thing
is true if you delete a user account that has files associated with it
through NTFS permissions. Once you delete the account, even if you
create a new account with the same name in the same domain, it still
will not be able to access the files.
As for looping routes and such, maybe you could explain that thought a
little more since I'm not sure what you're describing there. There is
some under-the-covers kind of authentication going on, however.
Cheers,
Russ
...due to licensing restrictions, this message can only be read by 10
people within 10 minutes...
>
|
|
