Re: IIS Certificate Mapping password retreival
From: Ohaya (ohaya_at_cox.net.NO_SPAM)
Date: 10/22/03
- Next message: Pascal Fluck: "Re: Authentication with tomcat"
- Previous message: David Wang [Msft]: "Re: Authentication with tomcat"
- In reply to: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Next in thread: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Reply: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 22 Oct 2003 01:08:54 -0400
Craig,
It's been awhile since I've worked with it, and perhaps I'm missing
something, but if you assume that you are running MS Certificate Server as
an Enterprise CA (vs. a standalone CA), when user requests a client
certificate, they have to authenticate themselves to Windows. Their Windows
username then gets embedded into the Subject (actually something like the
SubjectAlternate field) of the client certificate that gets issued.
Then, when the AD mapping occurs, the Windows username gets extracted from
the authenticated client cert, and is used to logon (via impersonation) as
that user.
The client certificate is signed, so client certificate authentication
implies (within limits of cryptography) that the username in the cert has
not been tampered with.
I guess what I'm saying is that, given the above scenario, I don't see where
the user's password gets exposed to the admin??
I think that you're correct that if you use AD mapping, that you need AD, or
perhaps more globally, you have to buy into a whole bunch of MS-specific
mechanisms, but then, why are you even looking at certificate mapping in the
first placel?
Presumably (and this may be a bad assumption), this is because you want to
enforce some kind of ACL or role/privilege in your system, and it seems to
me that the choices are use the infrastructure/mechanisms that MS provides
(AD, AD mapping, etc.), "roll your own" (i.e., implement the
roles/privileges in your application), possibly with the "help" of some
3rd-party products...
Sorry for rambling on, but we've been going through somewhat similar
ruminations ourselves :)....
"Craig Humphrey" <craig.humphrey@nospam.chapmantripp.com> wrote in message
news:u$7n$2EmDHA.1408@TK2MSFTNGP11.phx.gbl...
> Hi,
>
> Yeah, we looked at the AD method of mapping, which is based purely on the
> (not guaranteed to be unique) plain text Subject field (see the "Flaws
IIS6
> with AD(2003) Cert Mapping" thread in this newsgroup). As far as we're
> concerned, IIS does cert mapping more securely, and AD does it insecurely
> (relying purely on trusting the CA, which is OK if it's VeriSign, but not
so
> hot if it's your own).
>
> We've since found out that MS are going to drop the cert mapping in IIS
(too
> bad for all the people that run stand-alone webservers, now you HAVE to
have
> AD to do cert mapping).
>
> My main point from all this, is that even an administrator should not be
> able to retrieve usernames and passwords. It doesn't happen in the SAM,
it
> doesn't happen in AD and I presume it doesn't (normally) happen in
> LSASecrets. So why does it happen in the MetaBase for IIS?
>
> The future: we'd like to see AD's certificate mapping based on the certs
> serial number, public key or thumbprint, any of which are unique within a
> CA. That way passwords aren't exposed in the API and you get a strong
> one-to-one mapping of a certificate to a user account, which "scales" well
> (according to MS). The cost (performance) of doing this is probably less
> than AD's current method, since AD already has to extract the Subject from
> the cert, where as, if the comparison was made using the public key, no
> extraction is required, though you are comparing two larger streams of
text.
> So use the serial number, it still needs to be extracted, but it's very
> likely to be smaller than the Subject...
>
> Later'ish
> Craig
>
>
> "Wei-Dong Xu [MSFT]" <v-wdxu@online.microsoft.com> wrote in message
> news:r$r1V$DmDHA.576@cpmsftngxa06.phx.gbl...
> > Hi Craig,
> >
> > Thank you for replying and the detailed information about the
> troubleshooting!
> >
> > This api is provided for an administrator to manage the IIS mapping. So
> far as I know, there are two ways to map Client Certificates to a user
> > account. You can map them in Active Directory or you can map them in
IIS.
> The AD method does not require knowing the user's password. The IIS
> > method does require that the user's password be entered into the
metabase
> either with code or via Internet Services Manager. Any property in the
> > metabase can be accessed via code by an administrator account including
> things such as passwords. If the users are Domain users a more secure
> > way of accomplishing the mapping would be to map them in AD instead.
> >
> > Please feel free to let me know if you have any questions.
> >
> > Does this answer your question? Thank you for using Microsoft NewsGroup!
> >
> > Wei-Dong Xu
> > Microsoft Product Support Services
> > Get Secure! - www.microsoft.com/security
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
>
- Next message: Pascal Fluck: "Re: Authentication with tomcat"
- Previous message: David Wang [Msft]: "Re: Authentication with tomcat"
- In reply to: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Next in thread: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Reply: Craig Humphrey: "Re: IIS Certificate Mapping password retreival"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|