[SmartcardServices-Users] Question from a New Person Testing Smart Cards
Will Coleman
will.coleman at centrify.com
Wed Feb 23 15:11:43 PST 2011
Tim and All,
I have one more question -- after testing further, it seems that the mac
accepts the shorter of the two NT Principal Names. You fix for windows
worked, in that I changed the login name and not the Sam name and it
logged in fine using the longer ID string.
However, when I moved over to Mac, it would not log me on with the longer
string but the shorter string, or just the NT Principal name
³2001361506 at mil² and not ³2001361506170084 at mil².
How does one map those two names together on one account if it¹s even
possible? I tried adding a kerberos name through name mapping but that
didn¹t work - and it seems rather silly that people would be switching
their AD around every time a user would log into a mac vs. pc, so there
must be some setting that I¹m missing here.
Thanks and hopefully you can help.
Regards,
--
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