Tip:
Highlight text to annotate it
X
In one of the connection criteria in your Trust
is going to be the Network Path, then
it's really a good idea to set up
actually two Trusts -- one that makes reference
to the Network Path by its fully qualified domain name,
and the other that makes reference to it by its local
name. Now, that's really because,
depending on how your domain name lookup is handled,
a computer may return one or
the other when looking for the name of
that computer. So,
just to give you an example. If you are using
SDK-based connections, the SDK-based
connections do not do a reverse name lookup, and typically
they return the smaller number, or
the smaller -- just the local name.
In this case, it would be this local name right here.
The API-based Applications, they tend to do a reverse name lookup.
And they, they return the fully-qualified
domain name, including the domain. And so that
would be something like that. So,
since you, you know, if you are
setting up the, a trust,
and you would like this to work
under either circumstance -- whether it uses the fully-qualified
or not -- then, set up two Trusts.
Actually, it's even more complicated then that, depending on
how your domain is set up. Sometimes
the, you know, the -- I mean, sometimes
you, you, you will not find that a hard and fast
rule. Sometimes you will get back a local name, and
sometimes it will be a fully-qualified domain name.
Now, if you look at the bottom in the Notes on this
slide, you will also find there's some advice on
how to determine what the actual name
is that's being returned. And that is simply
look at the Message Log
when you attempt a connection. In the Message Log, we
will show what name we are getting from the Connection Credentials,
or what the connection -- the Connecting Client is
named. So, you can then base your Trust on that
name that you see in the Log. And one more thing.
If you are doing SDK-based Connections, if you put
a dollar sign in the Machine
Name, that basically means that it will match any machine
name that's going to be within that domain.
Now so far, I have not been really telling you the whole
truth about one of those Connection Credentials, and that's
the IP Address. See, when you specify the IP Address
as a Trust, you have to
also specify a Net Mask.
As you can see here, I have specified an IP Address
that ends in zero. This is a,
a Class C Subnet, and
ending in zero here and with the
Net Mask ending in zero, this, if you do the,
the, the traditional
Net Mask in a TCPIP Routing Table
kind of operation with Logical ANDing, it basically
means that any IP Address within the range of
zero to 255 is going to be allowed.
Now, if you were to switch this over to, say,
240 -- I have forgotten exactly what it is, but I
believe it's anything from zero to 16,
or zero to 15, is going to be allowed. I mean, there's subtleties where you
can specify individual
or, excuse me, specify through Net Masks,
an IP Address where, where
it basically, it allows a range of IP Addresses to come in.
And, that's truly beyond the scope
of this class to get into that Routing Table logic and the
Logical ANDing, so if you are familiar -- you know, those of you
familiar with TCPIP Routing will be familiar with this
topic. For anybody else, to be honest, I, I find it's a lot
easier if I need to create 16 Trusts
to just create -- or to, to have 16
Computers Trust, I just create 16 Trusts and they are
labeled 1 through 16. And, if I
mask this as 255 in all octets,
that indicates it needs a 100 percent
mat... match. So I would just create a MyTrust, for
example, MyTrust2 that matches to that,
MyTrust3, it matches to 3, etc.
Because this implies a full match is required.
Now we described that in the slide here.
If you look at our --
this is our IP Addresses
and Net Masks.
If you are specifying zeros in all octets,
for both the IP Address and the Net Mask,
then the incoming IP Address
is going to be allowed basically no matter
what. Because the result of the Logical AND
between this incoming address
and this Net Mask is going to match
what was defined over here. So, see, we are trying to match
how it's been defined in the IP Address. So, I will give
you another example. Here's an instance
in which we have defined the IP
Address to be zero. Our Net Mask is
ending in zero in the last octet. The IP Address
that we get from the Connecting Client
ends in 121. Okay.
The result of the Logical AND between this --
let me describe this better -- between this
and this -- the Logical Anding result of that ends up being
168.0, which, as you
can see, matches this, which means since
these two match, we are -- the Trust
mat -- the Trust IP Address that we have
specified matches the result of the AND, we do allow
a connection. Now, compare that to this
in which our IP Address is 168.
The Machine IP Address that we get is
175. Now, that 255
in the third octet indicates we need a 100 percent match
for these, but, of, of course, when we do the Logical ANDing,
we do not get that match at all. The
comparison of this to this fails,
so we do not get a connection there.
So, we could go on and on, but
the -- suffice it to say, if you are familiar
with the TCPIP Routing Table
and the Network Destination and Net Masking
capabilities, this supports that as well.