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

Will Coleman will.coleman at centrify.com
Wed Feb 23 12:42:06 PST 2011


Tim or Others,

I do have one quick follow-up question, How does the card ³tack² on the
additional digits to the ID without the middleware present?

For example, we have a query tool that I use to look at the card and there
is NO place that I can see those additional digits that are presented when
I plug in the card to windows 7 (178004) in addition to the NT Principal
Name which = 2001306561 + 178004 (something like that).  When I have
actividentity installed what I see is just the NT name (2001306561 at mil)
underneath the name of the card holder.  When I uninstall the
actividentity software I see the longer ID and NO additional ID to login
with (which is good, since that is the default value).

However, why can¹t I see that ID on ³keychain² access on the Mac?  Or
maybe I¹m not looking in the right place, but there is no place on the
certificate for the user of that card that shows the longer ID.  I¹ve
looked everywhere.  The only place I was able to see it is through a query
tool by actividentity on the windows machine and there is showed the
longer ID on the PIV cert.

Is there a way to query the PIV cert directly on the mac?  I¹m sure that
value is there somewhere.

Thanks,
-- 

William Q. Coleman
Centrify Corporation




On 2/23/11 8:36 AM, "Miller, Timothy J." <tmiller at mitre.org> wrote:

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



More information about the SmartcardServices-Users mailing list