Simon Says – Musings of a Technology CTO

A few people came to me this week and independently asked how to link EEM (SafeBoot) users to directory counterparts, or how to switch them to other directories or user names. Bindings are a key part of the EEM Encryption environment, as they allow automated user management to take place by tracking changes to the user identity in some other system, most commonly Active Directory. The answer’s quite simple and is shown in the user bindings properties of EEM

Typically. Two bindings are set per connector, and these both link the user to the connector itself, and also to their directory counterpart. The two common binding entries are”

Connectorname.username
Connectorname.changes

You can see in my example above, the username entry is not simply their user name, but is an obscure slashed out number. This is because we don’t use a fixed concept of what a “username” is – in the default Active Directory connector for example we use the attribute “ObjectGUID” – this is set in the connector/user information/user attributes page – the “Binding Attribute” field.  The entry is called connectorname.username for historical reasons – the first connector written back in 2001 only linked to NT, where the only choice was indeed username. The correct name should really be “connectorname.bindingname”, but hey, backwards compatibility bites everyone eventually.

We do this because we really need something fixed to relate the EEM and directory users together. There’s no fixed requirement for them to use the same naming convention (you can link EEM user “Joe” with AD user “Fred” if you wish), and of course if they get married, or change their name, we don’t want to lose connection between the two.

The connector drops in the connectorname.username binding after in this case escaping out the binary attribute (we know it’s binary again because of the connector\General\Attribute Types page, and if you look at the raw data with LDAPBrowser, again you’ll see it’s a binary attr).

We can use any attribute we like to link the user between the two directories, but objectGUID is the best because it never changes for the life of the user. Of course if you move users between domains though, or recreate them, it does change and in those cases its necessary to relink the users.

You can edit the connectorname.username attribute directly in EEM – just find the objectGUID attribute for your user and then type it in as a series of hex pairs, prefixing each one with a “\”. You can also use the LinkUser.vbs script to do it for you (I’ll talk more about this later).

Change Attribute

The connectorname.changes attribute maps again to one in the directory the connector is paired with, in this case linked to the attribute set in user information\user attributes\change attribute. The default for Active Directory is uSNChanged (a text attribute, even though it’s numeric), which is an incremental count of the revision of the user object in AD.

This counter has the nasty habits of

• not being synchronized across the domain, thus can be different on different controllers
• eventually rolling back to 0

This means if you point the connector at a different DC in your forest, you may find it syncs all users even though they have not changed, or, more annoyingly, it stops syncing users because their AD change attribute has a far smaller value than the last one stored.

Again, you can use LinkUser to reset this.

CertID Attribute

The final binding attribute you might see is connectorname.certid – this is used ONLY if you are using certificate (PKI) mode tokens, and is used by the connector to track which certificate in the users directory profile is being used for authentication (and to check CRL’s etc). If a value is set here, the connector assumes it has correctly created a PKI token for that user.

If you want to get a PKI connector to recreate a users token, simply clear (or delete) that binding. Yes, again, linkuser.vbs will do that if you ask it to, or you can edit the bindings directly in EEM.

Some final tips re bindings – there’s no restriction on how many connectors a user can be linked to, though the connectors themselves won’t add their entries to an existing user – the connectors will only pay attention to users they created themselves, or users where the bindings got added manually (or via a script). If a user does not contain a binding for the connector processing them, it will log a “<User> is not from this directory – Ignoring” message. Alternatively if the connector wants to add a user, and one already exists (either created manually, or created by another connector), you’ll get an “error adding user <user> .. the object already exists” message – the connector won’t take over, or replace existing users UNLESS those users are already linked to that connector.

An example of this would be if you create a user in EEM called “John” – no connector will pay attention to him unless you also go add some bindings (of course, if the connector created John, the bindings would already be there and they would be managed).

If you want one EEM user to be accessible to multiple connectors, either use linkuser to add the bindings, or do it manually yourself. You only need the connectorname.username binding to start the ball rolling.

Linkuser

The linkuser script is an example of how to programmatically handle bindings – its main purpose is to create the relationships between existing users and their directory counterparts. You can download this package from CTOGoneWild.

An example of why you need this would be perhaps if you’d set up a few users manually in EEM, but now wanted to use the connector to manage them – if you have created the users using the same naming convention (SAM account name or user principal name).

The script looks up the details for the specified user, and creates the bindings as appropriate, so for example if you had a EEM user called “Simon” and you wanted to map them to a directory user with the same name, you could use:

 Cscript linkuser.vbs /adminuser:admin _
 /adminpwd:pass /user:simon /connector:sbadmcon01

Which would output something like:

INFO: User binding for "shunt" is 3d47c763338f12418f1e00f5a9aef7b5
DEBUG: Running sbadmclAddBinding (shunt/test.username/\3d\47\c7\63\33\8f\12\41\8f\1e0\f5\a9\ae\f7\b5)...
DEBUG: New connection
DEBUG: Set binding for user "shunt"
SUCCESS: Added username binding to user
DEBUG: Running sbadmclAddBinding (shunt/test.changes/0)...
DEBUG: Existing Connection
DEBUG: Set binding for user "shunt"
SUCCESS: Added changes binding to user
DEBUG: Running sbadmclAddBinding (shunt/test.certid/)...
DEBUG: Existing Connection
DEBUG: Set binding for user "shunt"
SUCCESS: Clearned CertID binding for user
FINISH:

The linkuser script has a few options which can help in stranger situations, for example you can specify different EEM and Windows users (use the /user: tag for the EEM account and the /Winuser: tag for the Windows name) – this lets you create a relationship between differing names, perhaps for example between your AD root admin and the EEM “Admin” account.

Finally, you can use the /group: parameter if you want to link a whole group (or all groups using *) of EEM users to their AD counterparts – in this case the /winuser tag is ignored, and the script does the lookup assuming the EEM name is the AD SamAccountName.

Don’t forget that once you link an EEM user to an AD counterpart, the connector is going to configure them – this could involve removing, deleting, renaming, moving, or disabling them to match the directory information. It’s best to test things out before whole-sale linking your entire production environment.