[SmartcardServices-Users] Question from a New Person Testing Smart Cards

[Will Coleman]

Thanks Tim,

This is more information that I've been able to read online – by far.

I was able to dive a little deeper on the problem last night.  The two ids are actually one id - the second id was the actividentity id for the middleware I installed and this id worked on Windows– yea! - which more than likely means it will work on my Mac (when the setup is correct).  Now, I'm not sure why this is happening (I would imagine that the middleware picked up the credential and presented the right EDI/PI number and not the longer PIV number.  I hope I'm getting this correct.  Or it uses another cert (which is what I think you are saying).

When I uninstalled the driver, I was presented with just ONE ID and that was the longer number or the PIV cert – and NO actividentity card login PIN screen.  I am having a hard time understanding how to configure the AD to accept the longer ID (if that in fact is the correct EDI/PI number).  What I mean is that I entered in the longer value for the PIV cert into AD and that did not work, the credentials could not be verified (or something similar to that message).   See below, I ask this question on the EDI/PI issue.

You said "but this behavior can be changed to present all certs, or only certs with digitalSignature keyUsage."

This sounds promising, but I would imagine this is a GP change on AD that forces this for all workstations and those mac attached to the domain?  But, I have not found any information on how or where one does this policy change.

You said "FWIW, you will only see the PIV cert under two circumstances:  (1) you're using PIV middleware, such as will be installed by Windows Update; or (2) you've "activated" the PIV cert and are using CAC middleware (activation links the PIV cert to the CAC on-card PKI applet).

Is there a way to "deactivate" the PIV cert?

Yes you can.  You need to change the account's UPN to reflect the UPN included in the PIV certificate.  You do this through AD Users & Computers by simply changing the UPN and leaving the sAMAccountName alone.

[cid:4BDB170F-F60B-45D9-A537-ED02031B9672]

   [cid:C3A062A4-8B2D-49A0-A13E-5FF37DECCE03]  <--- This number will go in user login name (leaving sAM alone)

Got it, so the 2001361506 which is the sAMAccountName under the AD user leave that value alone and then change the userlogin to the longer ID which is 2001361506170084.  Why can I not query this number when using some tools that we've developed internally?  I should see this ID when I dump the card?  Does the keychain access tool show this number?  I was not able to find it, but more than likely I was looking in the wrong place.  Is there additional configuration necessary, I think I ask this in the next question.

You said "You will *also* need to include the PIV certificate issuing CA in the NTAuthCA certificate store. "

Ok, so in my case the issuer of the cert was CA-23, which I was able to download the certs and install them successfully and properly in AD.  This was for email, network auth and sign-on – there were three certs, one of which was DoD JITC Root CA 2.  Please note, these are all JITC certificates.  Is there a separate PIV cert that needs to be added to NTAuthCA?

FWIW, I can get you in touch with the AF PKI SPO helpdesk.  Only limited support can be given to independent vendors, but if you're working on an AF contract (even as a sub) more help is available.

Thanks a lot Tim, we are working with JITC, not sure how that relates to the Air Force, but this board is help enough.  I'm very new at this and I'm learning on my feet, but that's the nature of technology these days, learn or go home.

Just some further background on this testing project - I'm testing out the implementation of my DC/AD/CA with windows 7 before I move over to installing our software on the mac.  Our software is a identity management software that allows users of macs to authenticate against AD (using pkinit of-course).  We are not necessarily responsible for the customers implementation of AD, but for testing purposes I need to setup a system that can accept the JITC cards that I've received from the testing command.  We are also not really responsible for what the mac can or can't support CAC or CAC-NG card wise.  My understanding is that there is no support for 128k Oberthur cards, but all others should work.

But to bottom-line problem.  When trying to authenticate using a simple 72k Gem card on a windows seven attached to a DC/CA/AD controller that is setup to accept that card (it has all the working JITC certs and root) - the card works if 1) the actividentity software is installed and 2) you switch to the actividentity sign-on "picture" on login in Windows 7.  If I uninstall the drivers I am only presented the 1 identity which is the "PIV" cert.  I'm hoping some of the answers you give me above might solve this problem for both my domain setup and/or the client setup.

Thanks,

Will Coleman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20110223/b5fe9b4f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4BDB170F-F60B-45D9-A537-ED02031B9672.png
Type: image/png
Size: 15839 bytes
Desc: 4BDB170F-F60B-45D9-A537-ED02031B9672.png
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20110223/b5fe9b4f/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: C3A062A4-8B2D-49A0-A13E-5FF37DECCE03.png
Type: image/png
Size: 7525 bytes
Desc: C3A062A4-8B2D-49A0-A13E-5FF37DECCE03.png
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20110223/b5fe9b4f/attachment-0003.png>