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

Miller, Timothy J. tmiller at mitre.org
Wed Feb 23 08:36:05 PST 2011


On Feb 22, 2011, at 4:54 PM, Will Coleman wrote:

> My test environment is setup properly and I am able to successfully login via a windows machine using the Gov't issued smartcard into my local Active Directory instance (separately, I'm able to login using my Mac with an Active Directory supplied username and password).  However, there is a small problem, the govt issued smartcards themselves seem to have "two identities", one is a "NT Principle Name ID" (I believe) and the other is a PIV credential (with several additional numbers following the NT Principle Name.

NT Principal Name is Apple-speak for UserPrincipalName, a user object attribute in AD.  By default, Microsoft's PKINIT implementation uses the UPN to map the user certificate to an account.  Windows Server 2008 enables alternative mappings are possible using the altSecurityIdentities attribute, but (again by default) will be ignored if the UPN is present in the cert.  The UPN can be ignored via a registry change on the DC.

In Kerberos terms, the UPN is not a principal name, it's an "enterprise name" (NT-ENTERPRISE) which is defined as an arbitrary string that maps uniquely to a principal.  Unfortunately MS uses the format of a principal name (id @ realm) which is confusing to say the least.

The DoD Email Signature cert constructs the UPN from the EDIPI, followed by an "@mil" identifier.  The DoD PIV auth certificate constructs the UPN from the EDIPI, and the OC, OI, and POA from the FASC-N (see TIG-SCEPACS 2.2 for a full definition of these), and also uses an "@mil" identifier.

> The default sign-on credential is the PIV and in windows you can switch to another identity and successfully login to the Windows machine.  If you want to get an idea of what I'm talking about – take a look at these set of pictures I've posted on photobucket (I've scrubbed them of specific ID's)

There is no "default" sign-on credential, or more accurately there's no defined default.  Users should generally be able to choose the certificate for a specific authentication event.  However, some implementations automatically select the *first* acceptable certificate listed when the card is queried for certs.  Windows XP does this too.  This isn't exactly incorrect behavior, but as you can see it can lead to unexpected results.

Windows Vista and later will display credential tiles for all certificates on the card that meet the logon policy configured on the client; by default this means certificates that assert the Smart Card Logon EKU, but this behavior can be changed to present all certs, or only certs with digitalSignature keyUsage.

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).

> Macintosh unfortunately picks the default credential, in this case, PIV, which means I am unable to login using the smartcard – since I can't provision the ID in AD to work

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.

You will *also* need to include the PIV certificate issuing CA in the NTAuthCA certificate store.  This is already done for the production DoD PKI on most AD installations, at least in the AF.

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.

-- Tim



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1533 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/smartcardservices-users/attachments/20110223/ef656c56/attachment.bin>


More information about the SmartcardServices-Users mailing list