Screenshots do not always show the correct name of intermediate certificates due to an earlier CA name change following the Pointsharp and SecMaker merge.

1. Introduction

This document contains procedures you must do to be able to use the PoSC Net iD service. Some of the procedures are mandatory, and some are not. Some information is just to give a better understanding of functionality.

2. Prerequisities

The technical requirements your internal IT system must meet before you can start with the procedures below are:

3. Mandatory procedures

PoSC Net iD must have a public key infrastructure (PKI) when using the certificate trust model. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. The certificate trust model extends certificate issuance to client computers. Later during the issuing process, the users receive a sign-in certificate.

3.1. Set up the certificates for the domain controller(s)

Make sure your domain controller has the appropriate certificates for all domain controllers from your local CA.

Either distribute your own template or use the default templates.

The least required certificate template is Kerberos Authentication:

Kerberos Authentication

If you distribute your own template the least required Enhanced Key Usages are:

  • Client Authentication

  • Server Authentication

  • Smart Card logon

  • KDC Authentication

3.2. Distribute certificates to clients and servers

You can use the following procedure to distribute the appropriate certificates to each client computer in the account partner forest by using Group Policy.

Membership in Domain Admins or Enterprise Admins, or equivalent, in Active Directory Domain Services (AD DS) is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (http://go.microsoft.com/fwlink/?LinkId=83477).

All certificates needed are provided by Pointsharp and can be downloaded from the system webpage:

3.2.1. Distribute certificates to client computers by using Group Policy

It is mandatory to distribute this policy to the domain controller.

To distribute the certificates you must first add them by using the Group Policy Management Console, or snap-in.

This procedure describes how you add certificates to Trusted Root Certification Authorities and Intermediate Certification Authorities.

  1. On a domain controller in the forest of the account partner organization, start the Group Policy Management snap-in.

  2. Find an existing Group Policy Object (GPO) or create a new GPO to contain the certificate settings. Ensure that the GPO is associated with the domain, site, or organizational unit (OU) where the appropriate user and computer accounts reside.

  3. Right-click the GPO, and then click Edit.

  4. In the console tree, open Computer Configuration\Policies\Windows Settings\Security Settings\Public Key Policies, right-click Trusted Root Certification Authorities, and then click Import.

  5. On the Welcome to the Certificate Import Wizard page, click Next.

  6. On the File to Import page, type the path to the appropriate certificate files or click Browse... to select the root certificate file, and then click Next.
    Root certificate file:

    • SecMaker eID Root CA v1.cer

  7. On the Certificate Store page, click Place all certificates in the following store, and then click Next.

  8. On the Completing the Certificate Import Wizard page, verify that the information you provided is accurate, and then click Finish.

  9. Repeat steps 4 through 8 to add the additional certificates listed below, but instead of Trusted Root Certification Authorities you choose Intermediate Certification Authorities.
    Intermediate certificate files (.cer) are downloaded for the issuing CA or CAs of the service you use:

Apply the policy and make sure the certificates are distributed to all clients and servers.

3.3. Allowed issuers for domain logon

This setting is neccessary to be able to log on to Windows using the issued e-identities. Make sure you only trust an intermediate certificate and not the root certificate.

The easiest way is to configure this on your Enterprise Certificate Authority.

  1. Start a new mmc and add the snap in Enterprise PKI.


  2. Right.click Enterprise PKI and then click Manage AD Containers.


  3. Add the issuer you want to trust. Do not add the root CA, just the intermediate issuer which is Pointsharp eID 2 CA v1.cer.

  4. To do this manually, run the following command:
    Administrator Command Prompt
    C:\Certificates>certutil -dspuplissh -f Pointsharp eID 2 CA v1.cer NTAuthCA

     

    Administrator Command Prompt
    C:\Certificates>certutil -dspuplissh -f Pointsharp eID 2 CA v1.cer NTAuthCA
ldap:///CN-NTAuthCertificates,CN-Public Key Services,CN-Services,CN-Configuration,DC-showroom,DC-local?cACertificate

Certificate added to DS store.

Certutil: -dsPublish command completed successfully.

C:\Certificates>_

  5. Now your domain trusts the issuer for domain logon.

  6. Make sure all domain controllers can reach the following URLs on port 80 to be able to do revocation control.

3.4. UPN or certificate mapping

Use this to make sure that the user of the e-identity is the same as the user in the internal active directory (AD).

3.4.1. User principal name (UPN)

The Subject Alternative Name – Principal Name is the easiest way to match the certificate from the smart card or YubiKey to the local active directory.

Using email address as UPN

The service normally has the subscriber's e-mail address as Subject Alternative Name – Principal Name. The domain suffix @SHOWROOM.demo must match the suffix of the current subscriber. The prefix test.testsson can if necessary be updated for the subscriber in the active directory as the User Logon Name or User Logon Name (pre-Windows 2000). Note that User Logon Name and User Logon Name (pre-Windows 2000) do not have to be the same as long as one of them matches the prefix from the subscriber in Subject Alternative Name – Principal Name.

3.4.2. Certificate mapping

If you do not want to use the Subject Alternative Name – Principal Name to match a user in the active directory, you can also use the method called certificate mapping.

The down side of this is that only one certificate at the time can be used to log on to the active directory. If a temporary card is issued, the mapping must be done with the new certificate.

  1. Right-click the user in the active directory and select Name Mappings....

  2. Export the certificate from the smart card or the service and add the certificate to the user object.

3.5. Require smart card or YubiKey for interactive logon

Smartcard or YubiKey is required for Windows logon. This can be set in the computer settings as well as per user.

3.5.1. Set logon requirement on computer

3.5.2. Set logon requirement on user

  1. Under Account options, click Smart card is required for interactive logon, and then click OK.

3.6. Net iD Client

Make sure to install the Net iD Client on all computers that the smart card or USB token should be used for interactive logon at. Both servers and clients.

3.7. Use Net iD Web-extension in your browser of choice

This web extension is installed and activated automatically when you install Net iD Client. However, if you must install it manually, download it from the extensions page of your web browser and then follow the procedures below.


To use Net iD Web-extension in your browser of choice, configure Net iD Client with the following URLs in the registry or via GPO to be able to utilize Net iD Client Web-extension.

  1. Go to Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\SecMaker\NetiD\_Client\Plugin\AllowURL.

  2. Create two keys with the following values:

    NameData
    2https://*.pointsharpsecurecloud.com,full

     

  3. When done, your browser utilizes the Net iD Web-extension to be able to communicate with the hardware on your computer.

3.7.1. Turn on extention

If your extension isn't activated, you must activate it manually in your web browser.

4. Other procedures

4.1. Certificate Path Validation Settings (Gracetime)

All domain controllers cache the revocation list from the service. And if suddenly the Internet connection or revocation service is unavailable, there is a risk that login for users stop working. Since the revocation list is cached, there is an option in the active directory to allow login even if the cached revocation list is expired.

4.1.1. Allow login when cached revocation list is expired

This policy can be activated at any time and is effective immediately if the domain controller in question has the revocation list cached. It is not recommended to have this policy activated in runtime since this can give false positive and this can have the effect that you don’t get the failure until it is too late.


  1. To activate this function, activate the policy Certificate Path Validation Settings under Computer Configuration – Windows Settings – Public Key Policies – Certificate Path Validation Settings.

  2. In the Certificate Path Validation Settings Properties dialog, click the Revocation tab.

  3. Select the Define these policy settings check box, and then select Allow CRL and OCSP responses to be valid longer than their lifetime check box.

  4. Chose how many hours you want to allow this. Maximum is 2000 hours.

  5. Click Apply, and then click OK to close the dialog box.

4.2. DNS manipulation

If you don’t trust your internet connection, there is always the possibility to manually (or automatically) download the revocation list and create your own CRL distribution point on-premise. Just create a new DNS record for the host below and set up your own repository on-premise.

http://crl.pointsharpsecurecloud.com

Make sure to download the revocation lists (.crl) in question for each CA you are using, and put them in your own repository. They can be downloaded for each service from the pages listed below.

4.3. Smart Card Policies

This is not a mandatory procedure, but rather a recommendation.


  1. In the console tree, open Computer Configuration\Administrative Tempates\Windows Components\Smart Card.

  2. Disable the following policies:

    • Turn on certificate propagation from smart card

    • Turn on root certificate propagation from smart card

    • Turn on Smart Card Plug and Play service

5. Information and troubleshooting

5.1. Web browser support

https://docs.pointsharp.com/net-id-client/latest/nic-release-notes/nic-113-system-requirements.html

5.2. Troubleshooting

5.2.1. Turn on CAPI2 logging

The CAPI2 (CryptoAPI 2.0) Diagnostics is a feature available on Microsoft Windows Server.
With this you can troubleshoot issues related to:

  • Certificate Chain Validation

  • Certificate Store Operations

  • Signature verification

5.3. Update smart card drivers

Some smart card readers do not have their own drivers, and in those cases the common criteria certified driver from Microsoft is installed. It is recommended to always use the vendor specific driver for the smart card reader, if available. In all cases, a recommendation is to disable the power save option of the smart card reader to make sure all card events (in and out) are registered. If the power save functionality is used, it is likely that some events are missed since there is no power to the smart card reader.

Some vendors also have a smart card power option available in the BIOS setting, and recommended is to set this to always powered on.

5.4. Smart card logon on Windows

  1. A request is sent to the domain controller (DC 1) when a user (Klient) logs on. The request contains username, a time stamp, and a copy of the user's certificate. The username and the time stamp are signed with the user’s private key.

  2. The domain controller controls the certificate's validity through CDP (certificate distribution Point, Web Server CDP) to verify that the certificate isn’t revoked. If the certificate is revoked or if the CDP cannot be reached, the user is denied access to log on. The user will also be denied if the certificate has expired. The CRL (Certificate Revocation List) is stored in several places.

  3. The domain controller controls which CA (Demo CA v1 and Demo Root CA v1) issued the certificate and that the certificate chain is in the list with trusted issuers.

  4. The domain controller asks the AD (Katalog) which user who presents the certificates by the UPN in the certificate. The user will be denied access if he or she doesn’t exist in the AD.

  5. The AD will return the user's public key to the domain controller.

  6. The domain controller generates a session key for the user and encrypts it with the user's public key. The domain controller generates a TGT (ticket granting ticket) that is encrypted with the domain controllers’ skeleton key. The encrypted keys will be returned to the user in a PKI reply message, which the user will decrypt with his private key. The domain controllers’ certificate is controlled against CDP to check that it is not revoked.

If one of the steps in the authentication process goes wrong, e.g., that a CDP cannot be reached or that the certificate isn't valid, the user is denied to log on.

5.5. Microsoft guidelines

Guidelines for enabling smart card logon with third-party certification authorities:

Map a certificate to a user account:


  • No labels