archiveren

Tagarchief: ad

Because I actually got some requests on how to accomplish this on my previous Belgium eID post, a more technical post here… It’s a bit chaotic, so I hope you’ll figure the details out on your own ūüôā

I’m not reinventing wheels here. All of the things are loosely based on http://blog.debilloez.net/2010/12/ad-authentication-with-be-eid.html , http://setspn.blogspot.be/2014/10/configure-windows-logon-with-electronic.html and¬†https://social.technet.microsoft.com/Forums/office/en-US/4eae5d60-c90c-4238-82b7-67b0ac261b8e/eid-login-for-domain?forum=winserversecurity¬† , https://blogs.msdn.microsoft.com/spatdsg/2008/04/17/smartcard-in-2008-and-vista-national-id-card-no-upn-no-eku-no-problem/ and there even was a word document i can’t seem to find anymore…

You can have this up and running in less then an hour.

Requirements:

  • Active Directory Domain Services
  • Active Directory Certificate Services with Enterprise CA (in good circumstances, this role is NOT installed on your DC…)
  • Some server or workstation (Windows Desktop or Terminal Server or whatever where you want your users to log-on)

Configuration

Forest/Domain

Basically, the certificate chain consists of end-entity -> intermediate -> root ( -> globalsign, FEDICT made 2 roots)

Root needs to be in “Trusted Root Certification Authorities”, intermediate needs to be in “Intermediate Certificate Authorities” of all involved machines: DC, client, server.

Download all useful certificates from http://certs.eid.belgium.be/ (please script this)

“useful” meaning:

  • non expired root certificates
  • all non expired citizen intermediate certificates
  • (foreigner if your use case needs this)

For easy deployment: create a new group policy, and add the root’s to “Computer Configuration\Windows Settings\Security Settings\Public Key Policies\Trusted Root Certification Authorities” and the intermediates to the “Intermediate Certificate Authorities” store in the same location.

Deploy this GPO to all servers involved: Domain Controllers, IIS, RDP, …

ADCS

Make sure the “Kerberos Authentication” certificate template is made available for Domain Controllers on your freshly installed CA, DC’s have enrolled them, and have them actually available in the certlm.msc (this is the newer version of¬†Domain Controller Authentication template, which is a newer version of the very original Domain Controller template). On of them good enough). Make sure your general PKI is healthy.

DC

Create a user.

Export the authentication certificate from the smart card (either with the Be eID viewer or using certmgr.msc).

The mapping of a Be eID to an active directory user happens in Active Directory Users and Computers (dsa.msc). Go to a user, right mouse click, name mapping, and add the exported version of the Be eID authentication certificate here.

 

The DC’s also need a modification in the registry

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
"CRLTimeoutPeriod "=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider]
"AllowCertificatesWithNoEKU"=dword:00000001
"AllowSignatureOnlyKeys"=dword:00000001

 

Note: the new 2017 BE eID’s don’t require the AllowCertificatesWithNoEKU and¬†AllowSignatureOnlyKeys¬† anymore (as they actually set the correct EKU), old eID’s do.
CRL timeout is also not really required  if outgoing network access allows it.

Target

IIS/Terminal Server/Windows logon

Always install the eID middleware, download from https://eid.belgium.be/

And set the same registry keys again

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
"CRLTimeoutPeriod "=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider]
"AllowCertificatesWithNoEKU"=dword:00000001
"AllowSignatureOnlyKeys"=dword:00000001
"ForceReadingAllCertificates"=dword:00000001

Same notes on regkeys as above, for the newest eID’s only ForceReadingAllCertificates is really required.
ForceReadingAllCertificates is needed because the smart card contains 2 certs.

Windows Logon

You can use a eID for regular logon on a physical machine (with a reader – think cherry keyboard or terminals)

On the lock screen, logon but select smart card.
Rest should be self explanatory.

RDP host

It’s best to set an gateway in between, as NLA sometimes blocks smart card logon (or disable NLA, but not recommended).

Under normal operations, use mstsc to connect to an RDP, in the authentication windows select the correct smart card (authentication) and logon.

Once connected, you’ll notice a 1-4 seconds delay, just give it some time to tunnel the reader over the rdp connection and logon will occur.

On the computer you are using to connect to the RDP server, also set the registry keys and install the eID middleware (driver for the smart card), see below for more info.

IIS

To be updated…

Basically use the iisClientCertificateMappingAuthentication, which needs to installed as an additional feature, and us that from there on. It’s also possible to cover the mapping directly in asp. Will update this part if I find some time.

Client

The machine you’re actually working on, and connecting to the servers above.

Install the eID middleware, download from https://eid.belgium.be/

The chip on the eID itself contains 2 certificates: 1 meant for signing, 1 for authenticating.

By default, Windows only reads the 1 certificate on a smart card, and tries to use that one to authenticate. On the Belgium eID’s, this is the signing one. (plus, with pre-2017 certificates, it has a wrong EKU). So we need to configure the Windows Client to actually read both certificates and allow certificates without EKU… (Note, in the 2017 eID’s the correct EKU, client authentication, is actually set, but still on the 2nd certificate)

Registry keys!

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\SmartCardCredentialProvider]
"AllowCertificatesWithNoEKU"=dword:00000001
"AllowSignatureOnlyKeys"=dword:00000001
"ForceReadingAllCertificates"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters]
"UseCachedCRLOnlyAndIgnoreRevocationUnknownErrors"=dword:00000001
"CRLTimeoutPeriod "=dword:00000001

Also, same comments on regkeys as earlier.

Limitations

There are some limitations for this solution, such as the certificate-user mapping process, deployment of eID certificates to servers, exceptions when someone lost his eID, etc…

At tSF we did try to fix those limitations, using extra policies when a user forgot their smart card and give them an exception on the authentication policy, and by building some extra tools to manage all this way easier.

But of course I can’t share those… =)

Other way around, if you’re interested, you’re always free to contact tSF: https://www.thesecurityfactory.be ūüėČ

 

Advertenties

The change you are about to make will result in x permissions being added to the access control list.

A random, most unusable warning window, you can get when changing security entries in the ACE in Active Directory.
Google says not much about it, accepted that -indeed- the message exists…

It seems things are going to break, but in the end, it’s just a warning.

After some testing, things got cleared out.

Apparently, ADUC fires this warning when you have more then 8 entries in the ACE that are inheriting to sub-objects.

Nothing more, nothing less.

Just hit apply ūüôā

 

AdvancedSecurityWindow PermissionsWarning

Because there still is a huge lack of documentation about Microsoft AD RMS, here some hints and tricks to use!

  • First thing: irmcheck! Go use it!
  • Always check ntsf acl permissions on the server side files asmx-files.
  • ConnectionString for SQL is located in registry
    http://technet.microsoft.com/en-us/library/ff660033%28v=ws.10%29.aspx
  • MSIPC (RMS client 2.0 in windows 8 and office 2013) caches in registry and %localappdata%
  • ¬†REGISTRY:\Software\Classes\Local Settings\Software\Microsoft\MSIPC\<Server Name> \Template (HKCU or HKLM)
  • %localappdata%\microsoft\msipc
    Hint: you can delete huge file names with¬† “rmdir MSIPC /s” in cmd (for some reason it doesn’t work in powershell)success
  • Advanced troubleshooting on OSI Layer 7: fiddler! (enable https decryption) Really, put it in between! You’ll get some far more usefull error messages then “cannot connect to the server”, or “cannot use this feature without credentials”…
    Even better, go Wireshark (note: ssl mitm here…)!
  • The older MSDRM (RMS Client 1) puts everything in your %localappdata%\Microsoft\DRM . There you can find your user- & machine certificates, and templates.
    Regkeys under REGISTRY:\software\microsoft\msdrm
  • always check the IIS certificates! If there’s something wrong, nothing will ever work!

Please, open them up, they’re just XML-based, and contain a lot of information! For example, in the GIC-file you can confirm your RMS-location. Don’t bother trying to modify them, they’re hashed… But you definitely should check them for having :443 in their url’s (check this article)
GIC (Group Identity Certificate) = RAC (Rights Account Certificate)
CLC (Client Licensor Certificate)
CERT-Machine = SPC (Security Processor Certificate)

More about those 3 files in here

  • When you need to go deeper, use debugview (or something new: Trace Spy). This works for bot MSDRM and MSIPC
    Server-side and Client-side
  • Go and check Windows Event Logs. RMS Client doesn’t actually logs something there, but it can be a source of good information anyway!

In powershell is quite a hassle…

You need this http://technet.microsoft.com/en-us/library/ee221079.aspx
And this http://technet.microsoft.com/en-us/library/ee617271.aspx

Yes, that are the only cmdlets available…

Import-Module AdRmsAdmin
Import-Module adrms

First you need to create the virtual drive using new-pssdrive
Call it whatever you want

 new-psdrive -name test -psprovider adrmsadmin -root https://localhost

Browse to it

set-location test:\trustpolicy
or simply cd test:\

And now you have a virtual “drive” containing all the rms configuration.
You can even “dir”¬† and “cd” in it!

PS test:\trustpolicy\TrustedPublishingDomain> dir
Hive: Microsoft.RightsManagementServices.Admin\AdRmsAdmin::test:\trustpolicy\TrustedPublishingDomain
Id         DisplayName           Type                  CSP                   KeyContainer          CryptoMode
 --         -----------           ----                  ---                   ------------          ----------
 100        tsfdemo2013app1       Internal              AD RMS centrally m... AD RMS centrally m... 2

Here, you can run the cmdlets from the links mentioned above


 PS test:\trustpolicy\TrustedPublishingDomain> Export-RmsTPD -Path .\100 -SavedFile C:\users\tsfadmin.CORP\Desktop\file12
 3.xml
 cmdlet Export-RmsTPD at command pipeline position 1
 Supply values for the following parameters:
 Password: **************
 Please type in a confirmed password:**************
 PS test:\trustpolicy\TrustedPublishingDomain>