| Groups | Blog | Home |
iis security : Flaws IIS6 with AD (2003) Cert Mapping
anyone come across this: Test Setup: Win2003 AD server, with CA [including CA web interface] Win2003 Web Server CA set up to automatically issue certs to users (via public CA web interface). [Not ideal, but this has been done for business reasons, a manual step is included later to associate a cert with an AD account.] IIS6 setup to use AD Certificate mapping. [We're NOT using IIS cert mapping, see References below.] Two client certs, issued from same CA (above) with the same "subject" (user details), but at different times. One certificate (public key) is mapped (AD | Advanced | Name Mappings | X.509...). The other isn't. Security Flaw: Both certs can be used to authenticate for the same user! This is nice, since if a cert expires and is renewed, AD doesn't have to be updated. But it's also very bad. Historically, we set up a public facing CA web server and let users issue their own certs. We would then manually or automatically map the certs in IIS (using IIS cert mapping, not ADs). IIS would use the public key to achieve the mapping when a user presented their cert to a website. But when you use IIS - AD Cert mapping, it only uses the subject line and issuer from the cert (as it's most restrictive setting), rather than the public key itself! Admittedly, that's what the tickbox option states, but wouldn't it be more secure to use the public key itself (or one of it's unique properties?). So now it seems that the CA's web interface must be heavily restricted, since if two different people submit the same user details, even if only one cert is mapped (manually or automatically) in AD, they both are able to authenticate (via Cert) as the same user! Even if you set up the CA to require a manual validation step (by an Administrator), the onus is on the validator to check that a cert with the same credentials has never been issued before, or that the person requesting the new (duplicate) cert, has legitimate reasons for doing so. We issue 1000's of certs each year, if IIS - AD Cert mapping used the public key for mapping, then this level of responsibility could be diminished. It can't be that hard, after all, IIS Cert Mapping already does it. Or is this the prime reason why IIS Cert Mapping doesn't scale well (see ref below)? Cert Mapping Bug: If "Use Subject for alternate security identity" is turned off on the Add Certificate box, when setting up a cert mapping in AD, then instead of any cert from the same root CA being auth'ed, none are. Cert Mapping Bug (or security configuration setting somewhere?) The "Use Issuer for alternate security identity" is greyed out on the Add Certificate box, when setting up a cert mapping in AD. Not that you'd ever want to use this, talk about a security hole! References: AD 2003 Cert mapping http://www.microsoft.com/technet/treeview/default.asp? url=/technet/prodtechnol/windowsserver2003/proddocs/standar d/dsadmin_CertmapAD.asp [Note: procedure I followed to set up IIS AD Cert mappings] IIS Cert mapping "doesn't scale" http://support.microsoft.com/?id=216906 [Note: just some of the reasons why I want to us IIS AD Cert mapping] IIS5 & Win2k preSp4 cert mapping problem http://support.microsoft.com/default.aspx?scid=kb;en- us;324377 [Note: what are the odds of Win2003 having some of the same problems as preSP4 Win2k?] Soon'ish Craig
This is by design, the whole point of certificates is so that one can carry
credentials to distributed systems, without the need for a central authentication database. If users are allowed to create certificates without any verification on the credentials stored inside the certificates, then yes they can probably impersonate other users. Users need to be authenticated, before they are allowed to automatically generate a user certificate, or an administrator needs to review the anonymous certificate requests and confirm that the submitted information is correct. [quoted text, click to view] "Craig Humphrey" <Craig.Humphrey@nospam.chapmantripp.com> wrote in message news:1a66601c3879c$c516ce80$a601280a@phx.gbl... > Hi People, > > anyone come across this: > > Test Setup: > Win2003 AD server, with CA [including CA web interface] > Win2003 Web Server > > CA set up to automatically issue certs to users (via > public CA web interface). [Not ideal, but this has been > done for business reasons, a manual step is included later > to associate a cert with an AD account.] > IIS6 setup to use AD Certificate mapping. [We're NOT using > IIS cert mapping, see References below.] > > Two client certs, issued from same CA (above) with the > same "subject" (user details), but at different times. > > One certificate (public key) is mapped (AD | Advanced | > Name Mappings | X.509...). The other isn't. > > Security Flaw: > Both certs can be used to authenticate for the same user! > > This is nice, since if a cert expires and is renewed, AD > doesn't have to be updated. > > But it's also very bad. > > Historically, we set up a public facing CA web server and > let users issue their own certs. > We would then manually or automatically map the certs in > IIS (using IIS cert mapping, not ADs). IIS would use the > public key to achieve the mapping when a user presented > their cert to a website. > > But when you use IIS - AD Cert mapping, it only uses the > subject line and issuer from the cert (as it's most > restrictive setting), rather than the public key itself! > Admittedly, that's what the tickbox option states, but > wouldn't it be more secure to use the public key itself > (or one of it's unique properties?). > So now it seems that the CA's web interface must be > heavily restricted, since if two different people submit > the same user details, even if only one cert is mapped > (manually or automatically) in AD, they both are able to > authenticate (via Cert) as the same user! > > Even if you set up the CA to require a manual validation > step (by an Administrator), the onus is on the validator > to check that a cert with the same credentials has never > been issued before, or that the person requesting the new > (duplicate) cert, has legitimate reasons for doing so. We > issue 1000's of certs each year, if IIS - AD Cert mapping > used the public key for mapping, then this level of > responsibility could be diminished. It can't be that > hard, after all, IIS Cert Mapping already does it. Or is > this the prime reason why IIS Cert Mapping doesn't scale > well (see ref below)? > > > Cert Mapping Bug: > If "Use Subject for alternate security identity" is turned > off on the Add Certificate box, when setting up a cert > mapping in AD, then instead of any cert from the same root > CA being auth'ed, none are. > > > Cert Mapping Bug (or security configuration setting > somewhere?) > The "Use Issuer for alternate security identity" is greyed > out on the Add Certificate box, when setting up a cert > mapping in AD. Not that you'd ever want to use this, talk > about a security hole! > > > References: > AD 2003 Cert mapping > http://www.microsoft.com/technet/treeview/default.asp? > url=/technet/prodtechnol/windowsserver2003/proddocs/standar > d/dsadmin_CertmapAD.asp > [Note: procedure I followed to set up IIS AD Cert mappings] > > IIS Cert mapping "doesn't scale" > http://support.microsoft.com/?id=216906 > [Note: just some of the reasons why I want to us IIS AD > Cert mapping] > > IIS5 & Win2k preSp4 cert mapping problem > http://support.microsoft.com/default.aspx?scid=kb;en- > us;324377 > [Note: what are the odds of Win2003 having some of the > same problems as preSP4 Win2k?] > > Soon'ish > Craig > >
Thanks Eric,
but my point is that if I use IIS Certificate Mapping, this isn't an issue, since it uses the actual public key to do the mapping, not just the subject. We're trying to make the process of users acquiring certificates to be as quick and painless as possible (we're dealing with lawyers here). If we introduce a manual step during the certificate request stage (pity the poor sod who has to do that at 2am), it just adds delays. And then the user still has to go back to the CA website to retrieve the cert... Later'ish Craig [quoted text, click to view] >-----Original Message-----
>This is by design, the whole point of certificates is so that one can carry >credentials to distributed systems, without the need for a central >authentication database. If users are allowed to create certificates >without any verification on the credentials stored inside the certificates, >then yes they can probably impersonate other users. Users need to be >authenticated, before they are allowed to automatically generate a user >certificate, or an administrator needs to review the anonymous certificate >requests and confirm that the submitted information is correct. >
We have users authenticate with a username and password via basic
authentication over https, then when they request a user cert, the CA fills in the information based on the user object information. Users can then use the certificate in place of the username/password authentication. Are you allowing the users to connect anonymously when they request a certificate? Are you using a custom template? Do your certificates have a Subject Alternative Name with the users Principal Name? To the best of my knowledge, our subject fields don't contain enough information to authenticate users, it's the Subject Alternative information with the UPN that is used to authenticate the user. [quoted text, click to view] "Craig Humphrey" <Craig.Humphrey@nospam.chapmantripp.com> wrote in message news:020f01c387d6$dfbb96f0$a001280a@phx.gbl... > Thanks Eric, > > but my point is that if I use IIS Certificate Mapping, > this isn't an issue, since it uses the actual public key > to do the mapping, not just the subject. > > We're trying to make the process of users acquiring > certificates to be as quick and painless as possible > (we're dealing with lawyers here). If we introduce a > manual step during the certificate request stage (pity the > poor sod who has to do that at 2am), it just adds delays. > And then the user still has to go back to the CA website > to retrieve the cert... > > Later'ish > Craig > > > >-----Original Message----- > >This is by design, the whole point of certificates is so > that one can carry > >credentials to distributed systems, without the need for > a central > >authentication database. If users are allowed to create > certificates > >without any verification on the credentials stored inside > the certificates, > >then yes they can probably impersonate other users. > Users need to be > >authenticated, before they are allowed to automatically > generate a user > >certificate, or an administrator needs to review the > anonymous certificate > >requests and confirm that the submitted information is > correct. > > > >
Hi Eric,
what you're saying about authentication is true. Currently we use quite a different method for issuing certs, and the method we're working on for the new environment is also different again (a lot stronger). However, out of the box, MS's implimentation is flawed. AD only uses the Subject and Issuer lines of the cert's public key, to do the mapping, which can't be gaurenteed to be unique. And you can't make the mapping process stronger. All you can do is restrict users ability to request certs. If MS were to use the same cert mapping function in AD, that they use in IIS, no-one looses, everyone wins, with a more secure implimentation. Later'ish Craig [quoted text, click to view] >-----Original Message-----
>We have users authenticate with a username and password via basic >authentication over https, then when they request a user cert, the CA fills >in the information based on the user object information. Users can then use >the certificate in place of the username/password authentication. > >Are you allowing the users to connect anonymously when they request a >certificate? Are you using a custom template? Do your certificates have a >Subject Alternative Name with the users Principal Name? To the best of my >knowledge, our subject fields don't contain enough information to >authenticate users, it's the Subject Alternative information with the UPN >that is used to authenticate the user.
[rant]
We've had a bit of a discussion with the local Microsoft Technical support and their stance is that IIS (4, 5 & 6) use a "legacy" method of mapping certificates and that AD uses the "model that MS have adopted for the future". So you have two choices, a secure legacy method, or an insecure "modern" method... you choose... The techy did point out that you're supposed to trust your CA, which is fine, if it's VeriSign, since they go to great lengths to authenticate and validate certificate requests. But we issue our own (1000's per year) using MS's own CA, which we then have to wrap up in some super duper secure procedure/system, to ensure that the certificates it issues are unique and trusted. That's not our core business (we're a law firm) and what good is MS's CA if you have to spend a whole lot of time and money locking it (and the procedures around it) down tight? OK, so maybe MS's CA is only good for issuing certs in certain closed conditions, since even internal networks can't really be trusted. So perhaps I should be asking if anyone knows of a CA service (with web and management interfaces) that can easily be set up in a secure manor? [/rant] Soon'ish Craig [quoted text, click to view] "Craig Humphrey" <Craig.Humphrey@nospam.chapmantripp.com> wrote in message news:10d801c3888f$c2be5420$a401280a@phx.gbl... > Hi Eric, > > what you're saying about authentication is true. > Currently we use quite a different method for issuing > certs, and the method we're working on for the new > environment is also different again (a lot stronger). > > However, out of the box, MS's implimentation is flawed. > AD only uses the Subject and Issuer lines of the cert's > public key, to do the mapping, which can't be gaurenteed > to be unique. And you can't make the mapping process > stronger. All you can do is restrict users ability to > request certs. > > If MS were to use the same cert mapping function in AD, > that they use in IIS, no-one looses, everyone wins, with a > more secure implimentation. > > Later'ish > Craig
Don't see what you're looking for? Try a search.
|
June 2003
July 2003
August 2003
September 2003
October 2003
November 2003
December 2003
January 2004
February 2004
March 2004
April 2004
May 2004
June 2004
July 2004
August 2004
September 2004
October 2004
November 2004
December 2004
January 2005
February 2005
March 2005
April 2005
May 2005
June 2005
July 2005
August 2005
September 2005
October 2005
November 2005
December 2005
January 2006
February 2006
March 2006
April 2006
May 2006
June 2006
July 2006
August 2006
September 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
April 2007
May 2007
June 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
February 2008
March 2008
April 2008
May 2008
June 2008
| home · blog · groups | Questions? Comments? Contact the dn |