archiveren

Tagarchief: active directory

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

All official Belgium eID applications are eventually wrappers around the by FedICT provided eid-sdk, which on its turn is a Java applet… This Java applet has the possibility to authenticate any known Belgium eID against FedICT’s database. Even FedICT’s FAS service can be used as a saml-compatible authententication provider (adfs!)… But you don’t always want to use Java, or FAS…

Did you know, you can fully integrate the Belgium eID in a Windows environment?

Yes, ADFS, yes RDP, yes Windows logons, yes IIS… The fun part, it’s all built-in and you don’t need Java, and you don’t need FAS! ❤
Downside: you’ll need to do some user mapping yourself: your servers still need to map you to an account, and it still needs to authorize that account… So a little administrative overhead here (with FAS FedICT does this for you)

There are some other tricks needed, as for example to enable your client to read both certificates on the smartcard, and to map your eid to a “Windows” user account, but when that’s set-up, you’re good to go!

certlogon

The key to all this is the implicit certificate mapping feature of Active Directory Certificate Services working together with an enterprise PKI.

RDP/Windows

1

IIS

For IIS, the “SSLVerifyClient require” http specification is used to leverage cert-based client authentication. This should even work in other HTTP-servers, and in all major browsers.

http://wiki.cacert.org/ApacheServerClientCertificateAuthentication

Local auth

For the tricks above, you’ll need a functional Active Directory including integrated enterprise PKI environment.

Thanks to Vincent of mysmartcardlogon you can also run it stand-alone on your computer!
Unless you’re running Windows Enterprise, like me 😦
Plus, my laptop doesn’t has a built-in cardreader, so it’s ugly having to take an USB-cardreader to logon at mornings 🙂

The why?

Strong “Multi-factor” authentication is strong.
A certificate in either a virtual or a physical smartcard is always a bunch more secure than a password you’ll have to remember as a simple human being.

And an eID is obligatory in Belgium, you have to buy it anyway, so why buy yet another token for Multifactor AuthN from a 3th party provider instead of the one you already have?

It’s not confidential or secret technology, so if you’re interested in the exact how and what, just leave a comment 🙂

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

AD FS, STS, SSO, Claims, Realms, Tokens, SAML, WS-Federation, WS-Security, … All these fuzzy terms that where thrown at my last month…

The project was to implement AD FS (see title) in our environment.
The single and only purpose of AD FS is to create a “single sign on experience” between applications. Sign on on any website, and you can visit all other websites with that same account! (Only trusted websites that is, ofc…)
There are claims providers for Exchange OWA, Sharepoint. You can use it native in custom and cross-platform applications, on Microsoft Azure and in our case Office 365.
And because it’s based on an open standard, you don’t have to use .net, but you can use Java (jeej) as well! Or even php -> http://code.google.com/p/simplesamlphp/.
As long as your application is compatible with saml, you’re good to go!

So, all mentioned abbreviations also have a meaning! And if you want to know what it means and what their purpose is, read this article on msdn!

A more “conceptual” article you can read: A Guide to Claims-Based Identity and Access Control (2nd Edition)
Especially the part about “the airport” explains a lot 😛

Some more “academic” OASIS articles on WS-Trust and WS-Federation

And if you want to know more about WSDL, just read wikipedia 🙂