On 6/7/2011 7:43 AM, HOURY William wrote: > Hi Douglas, > > When I performed the test with different cards , I did request a certificate > from my MS 2003 CA and then export it as a P12 , and finally import this P12 > in both cards. > > Otherwise ,most of the time I use my tool which generates the keys on the > card , send a CSR to MS 2003 CA , retrieve the generated certificate and put > it into the card. > > I will try to play with the usernames. > > Yes the CA is an enterprise CA and is part of the domain. > > I'll try to put "blotito@PMTDOM.LOCAL" instead of "blotito@PMTDOM" but I was > thinking that if this would be an issue, we would face it every time and not > only before the 1st reboot. >
It should match the userPrincipalName attribute in the user's AD account. The userPrincipalName was originally the Kerberos principal. Then with the introduction of smart card support, Microsoft required it to be in the subjectAltName:otherName:msUPN in the certificate. This worked well for an enterprise CA, but meant the smart card was only usable with one domain. A 1-to-1 mapping between user and smart card. They then relaxed this with 2003, and Kerberos would check both the userPrincipalName and samAccountName@DOMAIN for a principal. But the smart card cert still had to have a msUPN. Thus a card could be used at multiple domains, if the msUPN was copied to the userPrincipalName. (The US PIV cards for example come with a msUPN like 123456...@fedxxx.gov so it can be used with 2003 and XP.) So all smart cards for the account have to have the same msUPN and any code that expected the userPrincipalName to be the real kerberos principal had to change. (I do that with some of my test cards and some admins that have 2 cards.) With 2008 and Vista, the msUPN is not required, but then the certificate has to be added to the user's account. Thus a many-to-many user-to-smart card mapping is now possible. (IMHO, the code that should have implemented in Windows 2000.) > > Yes the CA certificate is trusted by both the client and AD. > > Yes Clocks are in sync. > > Thanks ! > > William > > -----Message d'origine----- > De : opensc-devel-boun...@lists.opensc-project.org > [mailto:opensc-devel-boun...@lists.opensc-project.org] De la part de Douglas > E. Engert > Envoyé : lundi 6 juin 2011 16:07 > À : opensc-devel@lists.opensc-project.org > Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC > 12.1 > > > > On 6/6/2011 2:46 AM, HOURY William wrote: >> Hi Viktor, >> >> After more testing, it appears that the issue cannot be reproduced with all >> my certificates but only some of them. >> >> I put attached details about the cert I use most of the time. > > You say that you use the same certificate on multiple cards, > This would imply that you copy the cert and the key? But the cert > you sent was generated on Jun 1, 2011, last week. So you must > be generating new ones. Can you explain? > > Can you use different usernames in the different certs to test if > the problems are related to some confusion in the client > as to what certificate is on what smartcard. > > AD has a propagation delay, and if you are creating new certificates > and trying to use them, a DC may not see the new certificate. > > Is the CA a Microsoft enterprise CA and part of the domain? > > There might be an issue with with NotBefore for a new cert if the > client is not converting to local time, but comparing only the date. > > You had said that you were using Windows AD, and were using the > smartcard to login to AD. For smartcard login to AD the msUPN should > match the userPrincipalName attribute in the user's account in AD. > > openssl asn1parse -i -in BL_CertDetails.txt -strparse 489 -dump > shows the msUPN to be blotito@pmtdom > > The userPrincipalName usually has the username@REALM, where REALM is > the Kerberos Realm name that is upper case, and is fully qualified. > The AD domain is usually lower case and is often used with out being > qualified. So based on other info in the cert, it appears that > the domain name is pmtdom.local. So the msUPN should be > blotito@PMTDOM.LOCAL > > Windows 2003 relaxed the restrictions, and the userPrincipalName > still needs to match the msUPN, by may be something else, > for example in our case something like: 123456...@xxxxxx.gov > > (Windows 2008 and the Vista and W7 with the CNG, can go further > and don't require the msUPN, but AFAIK, XP still does.) > > Is the CA certificate trusted by both the client, and the AD? > > Are clocks in sync. > > The subject has C, ST, O, OU and emailAddress as NULL. Usually > these would have a value, or not be present at all. > >> >> Thanks >> >> William >> >> -----Message d'origine----- >> De : Viktor Tarasov [mailto:viktor.tara...@gmail.com] >> Envoyé : vendredi 3 juin 2011 16:53 >> À : Viktor Tarasov >> Cc : HOURY William; opensc-devel@lists.opensc-project.org >> Objet : Re: [opensc-devel] First Smartcard logon issue on XP SP3 with OpenSC >> 12.1 >> >> Le 03/06/2011 09:21, Viktor Tarasov a écrit : >>> Le 03/06/2011 09:06, HOURY William a écrit : >>>> Hi Viktor, >>>> >>>> I have other middlewares installed but I have disabled all the proprietary >>>> certificate propagation tools and only activated the windows one (the >>>> sccertprop registry value is well set). >>> >>> Ok, once more it hasn't worked. Thank you. >>> Will try to reproduce. >> >> >> For a while I cannot reproduce. >> >> The test was done with the card: >> Athena ASEPCOS >> atr: 3b:d6:18:00:81:b1:80:7d:1f:03:80:51:00:61:10:30:8f. >> >> Card initialized with the following commands: >> # pkcs15-init -E >> # pkcs15-init -C --label "IDX-SCM" -P --auth-id 53434D --so-pin "12345678" >> --so-puk "123456" --pin "9999" --puk "8888" >> >> >> Pkcs#12 with the 'SmartcardLogon' + 'Client Authentication' certificate is >> imported by : >> # pkcs15-init -a 53434D --label "basic user smartcard logon" -S >> basic_user.p12 -f pkcs12 --passphrase coucou --so-pin "12345678" --pin >> "9999" --key-usage digitalSignature,dataEncipherment --cert-label "basic >> user smartcard logon" >> >> (Don't know why with the key usage derived from the certificate extensions >> it's not worked.) >> >> >> The first login to AD on the XP platform is OK . >> Also works the sequence 'clean-up personal key store'> log-off> log-in. >> >> >> Kind regards, >> Viktor. >> >> ________________________________ >> >> >> Ce message et les pièces jointes sont confidentiels et réservés à l'usage >> exclusif de ses destinataires. Il peut également être protégé par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne >> pouvant être assurée sur Internet, la responsabilité du groupe Atos Origin >> ne pourra être recherchée quant au contenu de ce message. Bien que les >> meilleurs efforts soient faits pour maintenir cette transmission exempte de >> tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa >> responsabilité ne saurait être recherchée pour tout dommage résultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended solely >> for the addressee; it may also be privileged. If you receive this e-mail in >> error, please notify the sender immediately and destroy it. As its integrity >> cannot be secured on the Internet, the Atos Origin group liability cannot be >> triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> >> _______________________________________________ >> opensc-devel mailing list >> opensc-devel@lists.opensc-project.org >> http://www.opensc-project.org/mailman/listinfo/opensc-devel > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
