Leveraging Smart Card Beyond Logons

While working with a customer recently, an interesting need came up that required me to rummage through my treasure-trove of random PKI and certificate knowledge. This was apparently so well hidden, I had to reach out to an old friend still at Microsoft to remind me what the heck it’s called!

One of the things that smart cards do is help increase the overall assurance level associated with an authentication requests. We can configure specific users to require the use of a Smart Card (great idea for privileged accounts) or can even mark a specific computer to only accept Smart cards (such as a server or system in a DMZ). By enforcing smart cards, we have a much butter quality of authentication and can ensure the strength of our issuance (such as face to face) is preserved.

But what about maintaining that level of assurance beyond the authentication/logon stage? Perhaps you have a critical file server, document repository or information that you really need to maintain a strong control over. It would be helpful if we could determine HOW someone authenticated and grant access accordingly. This would enable you to configure a normal day-to-day file server will accept any authenticated user with proper permissions. The server really doesn’t know or care if the user logged on with a RSA token device, smart card, Windows Hello, or a super simple password.

So if we want to protect a system/information and enforce access based on the level of authentication the user used, we need a method to do that. File servers, sharepoint and other systems are all controlled through permissions given to users and groups with Access Control Lists (ACL). But there is no native method to allow a file server to allow access ONLY if a user logged on with a smart card. So how can we achieve this.

Back in the far corners of my mind, I remember teaching about something that could do this – way back in the days. Eight years ago when we were teaching the Microsoft Certified Master – Directory Services track, we talked about an assurance process that would indicate if a user authenticated themselves with a Smart card – exactly what my customer needed.

So what is this miracle process? Microsoft calls it the Authentication Mechanism Assurance service. What exactly does this do? Once properly configured, when a user authenticates with a Smart card, the user will be temporarily placed in a security group. This security group can be used to ACL information repositories, file shares, sharepoint, etc… When the user logs out, they are removed from the group. Essentially the user will only be allowed to access the resource if they have logged on with a smart card! Bingo!

There are several components requiring configuration – including adding a custom OID to your smart card certificates. When a user authenticates with a smart card and the user certificate has this OID, they are mapped to a specific security group. This means you can have several OIDs that correspond to being placed into different groups. So your normal users could be mapped to one security group, and privileged accounts (with a different OID) could be placed into yet another group.

There are also a few caveats, such as requiring the target security group to be empty and be untouched outside of this service. AMA can not add and remove users dynamically if the group contains users you are also adding and removing. It also requires the use of a few scripts to find the correct objects in AD and make the symbolic connection. Luckily, there is no on-going, scheduled, or triggered script that makes this works. It just requires proper configuration and it will then be replicated to all of your DCs to do all the heavy lifting.

So all this enables you to specify specific resources in your environment that will only accept a given user if they also logged on with a smart card. Very cool indeed. Do you have a need for something like this? You probably do, but because it’s little know, it probably hasn’t bubbled up to the top of your project list – until now! Have fun!