Re: IIS Certificate Mapping password retreival

From: Craig Humphrey (craig.humphrey_at_nospam.chapmantripp.com)
Date: 10/23/03 

Date: Thu, 23 Oct 2003 15:18:48 +1300

Hi Ohaya,

See inline comments:

> Actually, I understood that :)...

:)

> I don't think that that above is completely accurate... I agree that
> "Active Directory Mapping" uses the info in the Subject field of the
> client cert, but:
>
> a) When you have/use Certificate Server that is configured as an
> Enterprise CA, from my testing, you have to first have each user created
> as a User in Active Directory (and thus the same User "under Windows")
> before the user can request a client cert.

That is correct, but the certificate that AD automatically creates for a
user (assuming you have it configured to do so), never reaches the user's
computer and is never (automatically) configured to acheive certificate
mapping in IIS (using the Use AD Cert Mapping in IIS), because the cert
isn't placed in the Name Mappings collection.

> And, you cannot (as far as I know - I just tried it) create the have the
> same user in AD, so that means that each time you create a new user,
> it'll have to be unique.

Correct. But, assuming that you have a default CA install (including web
service), you don't need to authenticate and you can supply all the details
(including those that go into the Subject line) manually. At this point,
the user's username isn't involved.

OK, so you can lock down the CA and have wide awake admins who only approve
certs that can be truely validated to going to the correct user.... (oh
gee... I've just implimented VeriSign.... :)

Or, you can use IIS's built-in cert mapping, which doesn't use the Subject
line and therefore is tied to a uniquely issued cert.

> b) When the user uses, say, IE to request a client cert at
> http://mymachine/certsrv, that user must authenticate as a User against
> Active Directory (which, again, is unique). The info from AD is then
> used to populate the Subject field in the client cert (which, again,
> means that among all the certs issued by this Certificate Server, each
> client cert will have a unique Subject).

Not by default. No authentication is necessary "out of the box". I must
admit, I haven't tried installing the web part of the CA (we're testing on
Win2003) in such a way as to force authentication and seeing if that
automatically puts the user's username in the subject line. From examining
the certificate issuing code, it doesn't appear to. And, to make matters
worse, since the private key is actually created on the user's PC, (using an
ActiveX control), they could completely spoof the input anyway (hmmm....
must try that some time).

> I'm not clear what you mean by "these certs are not able to be used
> logging into say IIS", BUT, instead of doing #2 above (which is actually
> IIS mapping, not Active Directory Mapping, I think), have you tried the
> procedure in the Section "Enable the Active Directory Mapper in IIS 5.0"
> on this page:
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;q272175
>
> This procedure does NOT cause the client certs to be stored into the
> Active Directory (or anywhere else on the server from what I can
> tell)... I have verified this myself using LDIFDE to dump Active
> Directory. Nor does it store any username or password info into Active
> Directory.

This is exactly what we were doing in my Point 2. (I've snipped it out)
All it stores is the Subject line.
Word from MS, is that this is "by design" and "you have to trust your CA,
don't you trust VeriSign, et al?", to which we reply "security layers" and
"we're our own CA and we're using MS's CA server, why, can't we trust it out
of the box?" :)

The system that's under development includes a stronger, one-shot mechanisim
for issuing certificates to users (outside the firm), but is still reliant
on a wide awake administrator to "click the OK button", so to speak.

I think we need to do some more playing around. But I'm worried that what
ever we come up with:
a) will rely heavily on an Administrator to get it right
b) will place unnecessary trust in our CA (we're not in the business of
building super strong authentication/validation/audit mechanisims for
issueing certs)
c) will become obsolete or incompatable with whatever MS dreams up next. (MS
have stated that the built-in Cert Mapping in IIS is to be dropped.)

If MS want us to trust their CA Server, then build a trust-worthy CA Server,
or at least provide some documentation on "best practices" for securing the
issuing of certificates.

> From what I can tell (and I'll admit that this is only from my testing,
> as I never got a clear explanation despite numerous posts), the way that
> this "Active Directory Mapping" works is:
>
> 1) Client connects to IIS
> 2) Client and IIS mutually authenticate ==> cert is valid and unaltered
> 3) IIS extracts the "username" (I think it's referred-to as the UPN
> actually) from the client certificate
> 4) IIS impersonates the user per the username, and logs into Windows as
> that user.
>
> In other words, this mapping is done kind of "statelessly", just based
> on the info in the client certs themselves.
>
> Using ASP, you can actually verify that with the above, the user is
> really logged into Windows as that user, BTW.

Yeah, we're already using this in our existing system (on NT4, no AD) and it
works very well. The IIS process actually grabs the username and password
from the MetaBase and logs in using those credentials. Neat, but according
to MS "it doesn't scale" and "it's not future proofed" and "it's going to be
dropped".

IIS when using AD Cert mapping, does it differently (and I don't exactly
know how it does the impersonation), allowing AD to do the mapping
functionality.
Presumably this means that whatever account IIS uses to do the mapping, has
sufficient priviledge to impersonate a user, without the use of a password
(scary!).

> I know that this is really confusing.
>
> The MS docs seem to be really inconsistent in the way they discuss
> mapping. Some docs talk about "Windows Directory Mapping", and some
> others talk about "Active Directory Mapping".

True, although, both are the same thing. Just read "Directory Mapping".

The main thing I'm confused about is that IIS's built-in certificate
mapping, which has been around since at least IIS4 (never used IIS3), is a
"strong" one-to-one mapping, regardless of the trustworthyness of the CA.
(OK, there's the password retreival flaw, but that's a different matter).
And then, in AD, Microsoft elected to do it differently, which probably
incurs a greater overhead, than IIS's built-in method. And now, MS are
going to drop the IIS built-in method (longhorn?).

> Before we go on, I hope that you understand and believe that none of
> the above is intended to be "flaming". Like I said in a previous post,
> I've been through a lot of this earlier when I was testing, and I got
> some help on these NGs, but there's still some stuff that I never did
> get clear answers on, so I understand how confusing all of this is (and
> MS' docs on their websites sometimes make things even more confusing,
> e.g., with the naming).

No problem. I've being doing cert mapping (in IIS4 without AD) for three
years now and it's only now that we've had the chance to re-write the system
(moving to .NET and Win2003 in the process), that we've taken a close look
at our process and the underlying tech that we're using. And it came up
short, with trade-offs all over the place.

> One last thing: I heard awhile ago that support for Certificate Server
> issues was moved over to the Active Directory NGs. This is one of those
> that I never got a clear answer on, but maybe if you go there, you can
> get more confused like I did :). I think that there are MS people over
> there who are involved in AD.

Well, my original post was cross-posted to the microsoft.public.adsi.general
group, but I only got a response in this group.
I might post it again and see what bites...

Thanks
Craig

Quantcast