Question from a New Person Testing Smart Cards
Hi All, Thanks for putting this board together, it's extremely helpful. I have a question with an implementation I'm struggling with. I've setup a single server with both a CA / AD and DC configured. I am testing smartcards from JITC (Government Issues SmartCards) for a company that provides software for corporations that would like to use Active Directory for identity management on Macintosh. The crux of our solution allows users to be provisioned in Active Directory and then have the ability to login using those credentials into their Macs. 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. 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) Here is the album with the three photos that are annotated – I think this will make much more sense for everyone. Hopefully everyone understands photobucket. http://s1097.photobucket.com/albums/g355/wqcoleman/Smart%20Card%20Login%20Op... 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 – I get a "credentials cannot be verified when I try to login using the PIN". I have the advantage of selected the proper credentials in Windows 7, but again, Mac does not allow this and I'm sure there is some configuration in either Mac, Active Directory or somewhere that will either 1) force the credentials that is working for login (see picture with the NT Principle Name) or 2) allow me to provision the PIV credential into AD and allow for the user to login? Please accept my apologies for not using the proper nomenclature, I'm learning this as fast as I can and it's been a crash course in smartcards, certs, etc.. Thanks in advance for any help, -- William Q. Coleman Centrify Corporation
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
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
On Feb 23, 2011, at 1:12 PM, Will Coleman wrote:
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).
EDIPI@mil comes from the DoD Email Signing cert. EDIPI+OC+OI+POA@mil comes from the PIV Authentication cert. If you examine both side by side it should be clear what's what. FWIW, the OC+OI+POA are fixed for a given subscriber affiliation; i.e., you can distinguish contractor from civilian from military along with service branch with these codes.
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).
If you've set the UPN correctly in AD U&C, then your problem is probably the NTAuthCA store. You can check this store using the MMC console: http://support.microsoft.com/kb/295663
You said "but this behavior can be changed to present all certs, or only certs with digitalSignature keyUsage."
You'd probably benefit from reading this: http://msdn.microsoft.com/en-us/library/bb905527.aspx
Is there a way to "deactivate" the PIV cert?
Not at this time. Currently CACs are issued with the PIV cert un-activated, but any user can activate the PIV cert though the UMP-PIP application hosted by DMDC. In addition, anyone using PIV middleware (e.g., the PIV tokend on OS X) will *always* see the PIV cert.
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?
You should be able to. The AD attribute is described here: http://msdn.microsoft.com/en-us/library/ms680857(v=vs.85).aspx You will need to bind to AD to do the query, though.
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.
It's in the cert itself. OS X will display it as "NT Principal Name" under the Subject Alternative Name extensions of the cert.
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?
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.
What's happening here is you actually have two smartcard middlewares installed. One is ActivClient, which is a complete CAPI CSP. The other is a PIV smartcard "minidriver" MS released under the Base SmartCard CSP framework. See here: http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac... Win7 will fetch this minidriver from WSUS when it detects a PIV smartcard. Unfortunately this driver isn't completely appropriate for CACs. It'll work, but there are differences between it and ActivClient. -- Tim
Tim, Thanks again for helping here. I have one more question based on your answers below -- William Q. Coleman Centrify Corporation
What's happening here is you actually have two smartcard middlewares installed. One is ActivClient, which is a complete CAPI CSP. The other is a PIV smartcard "minidriver" MS released under the Base SmartCard CSP framework. See here:
http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599b ac8184a/sc_minidriver_specs_V5.doc
Win7 will fetch this minidriver from WSUS when it detects a PIV smartcard. Unfortunately this driver isn't completely appropriate for CACs. It'll work, but there are differences between it and ActivClient.
I know that it¹s possible to shut off this ³mini-driver² system and ignore Win7¹s detection mechanism. If do this, remove Actividentity, then I have no real help here? Since I need some middleware to handle the card, otherwise, there are no drivers to handle this problem. If Win7 defaults to the PIV cert, then it will only accept that longer EDI/PI number in AD (which works fine btw). However, to have one sign-on, the Mac needs the shorter CAC EDI/PI number, which also works. I¹m just thinking out loud here, in that one disabling all the available smart-card middleware, you are really still stuck since you have nothing to help windows read the card for authentication, correct?
On Feb 24, 2011, at 3:42 PM, Will Coleman wrote:
Tim, Thanks again for helping here.
In case you haven't guessed, my working day is spent supporting the DoD CAC program. :)
I¹m just thinking out loud here, in that one disabling all the available smart-card middleware, you are really still stuck since you have nothing to help windows read the card for authentication, correct?
Correct. Windows won't be able to use any of the keys on the card. If the certificates are already registered in CAPI the system might *try* to find the keys, but it will fail (it will likely prompt you to either insert the card or install the necessary middleware). You must have middleware of some sort. This is true on OS X too, but Apple bundles CAC and PIV middleware with the system. -- Tim
All, Thanks a ton for all your help! - I got it working just now. Tim, you suggestion was the trick in leaving the samAccount name the same and change the EDI/PI. Thanks a ton everyone! I¹m sure now attaching the mac to the domain it will work, since the default ID is now working with the pin. Regards, -- William Q. Coleman Centrify Corporation On 2/23/11 8:36 AM, "Miller, Timothy J." <tmiller@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
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@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@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
On Feb 23, 2011, at 2:42 PM, Will Coleman wrote:
I do have one quick follow-up question, How does the card ³tack² on the additional digits to the ID without the middleware present?
It doesn't.
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@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).
You're looking at completely different certificates. The PIV minidriver shows you the PIV cert with the extended UPN syntax. ActivClient (by default) show you the DoD Email Signature cert with the shorter EDIPI-only UPN syntax. (FWIW, they actually use different smartcard interfaces; the PIV driver uses NIST SP800-73 and ActivClient uses GSC-IS 2.1. AC can use SP800-73 *as well* but it's not on by default in the CAC version.)
Is there a way to query the PIV cert directly on the mac? I¹m sure that value is there somewhere.
To see the PIV cert on the Mac you need PIV.tokend to take ownership of the card. Currently the CAC.tokend (or CACNG.tokend, if installed) wins because securityd prefers it. You can move the CAC.tokend package *out* of /Security/Library/Security/tokend and re-insert the card to drive it as a PIV. -- Tim
Tim, See below: --
You're looking at completely different certificates. The PIV minidriver shows you the PIV cert with the extended UPN syntax. ActivClient (by default) show you the DoD Email Signature cert with the shorter EDIPI-only UPN syntax. (FWIW, they actually use different smartcard interfaces; the PIV driver uses NIST SP800-73 and ActivClient uses GSC-IS 2.1. AC can use SP800-73 *as well* but it's not on by default in the CAC version.)
Is there a way to query the PIV cert directly on the mac? I¹m sure that value is there somewhere.
To see the PIV cert on the Mac you need PIV.tokend to take ownership of the card. Currently the CAC.tokend (or CACNG.tokend, if installed) wins because securityd prefers it. You can move the CAC.tokend package *out* of /Security/Library/Security/tokend and re-insert the card to drive it as a PIV.
-- Tim
Frankly, I don’t have a need to see the PIV cert on the mac, I’m fine with the CAC token and that works just fine, I just want to setup a consistent architecture that I can test on both Win7 and Mac, and I posed a separate question to you in the previous email about disabling Win7 mini-driver architecture to see if that might work (in addition to killing the AC software, but I’m supposing that will hose the Win7 machine to see NOTHING. But, again, I’m not sure here.
On Feb 24, 2011, at 3:46 PM, Will Coleman wrote:
Frankly, I don’t have a need to see the PIV cert on the mac, I’m fine with the CAC token and that works just fine, I just want to setup a consistent architecture that I can test on both Win7 and Mac, and I posed a separate question to you in the previous email about disabling Win7 mini-driver architecture to see if that might work (in addition to killing the AC software, but I’m supposing that will hose the Win7 machine to see NOTHING. But, again, I’m not sure here.
You should be able to suppress the Win7 PIV minidriver and use the AC middleware. This *should* work just by installing AC, but it may be that it depends which modifies the registry hive last, and you might find yourself in a position where WSUS has stomped over AC and the PIV minidriver takes over. I'd have to ask one of the AF PKI SPO's integration engineers to be certain what's safe; I know they've addressed this situation in the recent past. -- T
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@mil² and not ³2001361506170084@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@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
On Feb 23, 2011, at 5:11 PM, Will Coleman wrote:
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@mil² and not ³2001361506170084@mil².
See my previous; this is probably because OS X sees the card as a CAC & automatically selects the email signing cert which only has the shorter UPN.
How does one map those two names together on one account if it¹s even possible?
The only way to do this is to set the DC to ignore the UPN entirely and use the altSecurityIdentities attribute to map the cert to an account: http://technet.microsoft.com/en-us/library/ff520074(WS.10).aspx You can map both cert to the same account, but you'll have to use altSecurityIdentities to do so. See the Windows Vista Smart Card Infrastructure doc I linked to earlier for more, plus this blog post: http://blogs.msdn.com/b/spatdsg/archive/2010/06/18/howto-map-a-user-to-a-cer... Bear in mind that this is *not* currently the standard configuration for DoD AD smartcard logon. You can play with it, and it may someday be deployed in wide use, but for now it's not a supported configuration in any CC/S/A I'm aware of. -- Tim
Tim - see below: --
The only way to do this is to set the DC to ignore the UPN entirely and use the altSecurityIdentities attribute to map the cert to an account:
http://technet.microsoft.com/en-us/library/ff520074(WS.10).aspx
You can map both cert to the same account, but you'll have to use altSecurityIdentities to do so. See the Windows Vista Smart Card Infrastructure doc I linked to earlier for more, plus this blog post:
http://blogs.msdn.com/b/spatdsg/archive/2010/06/18/howto-map-a-user-to-a-c ertificate-via-all-the-methods-available-in-the-altsecurityidentities-attr ibute.aspx
Bear in mind that this is *not* currently the standard configuration for DoD AD smartcard logon. You can play with it, and it may someday be deployed in wide use, but for now it's not a supported configuration in any CC/S/A I'm aware of.
-- Tim
I took a look at this (interesting to be honest, but a hack none the less), and in many respect we don¹t care if the user setups up their AD this way, it¹s not up to us. Again, my goal here was to setup a consistent architecture that would accept both CAC certs on both Mac and Win7. If I can get a consistently running machine that I can baseline on the Windows machine and then test eventually on my Mac, I¹m all set.
participants (2)
-
Miller, Timothy J.
-
Will Coleman