Home > Mastercard/McAfee/SafeBoot/Intel, Programming > About Bindings in McAfee Endpoint Encryption / SafeBoot

About Bindings in McAfee Endpoint Encryption / SafeBoot

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

Connector Bindings in 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”


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.


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

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.

  1. Phil Crofts
    November 3, 2009 at 11:52

    Thanks for this, you fixed a big problem for me.

  2. Darron Lightbourne
    December 15, 2009 at 08:22

    Great post, but I’m running into a problem using the LinkUser.vbs script. Our domain controllers were recently migrated from 2K3 to 2K8. The uSNChanged attribute was reset for all of our users and now users are no longer updated via the connector due to the inferior value on the DC side.

    I have been attempting run the linkuser script against a single user to test but am getting the following error:

    Cscript linkuser.vbs /adminuser:SBAdmin /adminpwd:”xxyyzz” /user:Tom /connector:SBADCon02

    ERROR: GUID for User “Tom” could not be retrieved from the Activedirectory

    I have also ran the command with the group parameter and received another error:

    Cscript linkuser.vbs /adminuser:SBAdmin /adminpwd:”xxyyzz” /group:SomeGroup /connector:SBADCon02

    C:\Program Files\McAfee\Endpoint Encryption Manager\linkuser.vbs(2186, 2) Microsoft VBScript runtime error: ActiveX component can’t create object: ‘SbAdmCom.SbAdmScripting’

    I tested the SBADMCL AddBinding command against a user successfully and the binding updated correctly. The user that was not updating prior to the binding change now synchronizes correctly.

    Any ideas why I’m having trouble with the LinkUser.VBS script?

    Any help will be greatly appreciated.



  3. Simon Hunt
    December 15, 2009 at 08:35

    first error is because there is no user with a SAM “Tom” in the AD you are currently logged into, 2nd is because you either don’t have the API installed, or forgot to register it? You need the COM version, so don’t forget to regsvr32 sbadmcom.dll etc.

    • Federico
      October 12, 2012 at 15:25

      Hi Simon – I’m also getting the error saying ERROR: GUID for User “xxxx” could not be retrieved from the Activedirectory.
      When you say the AD you are currently logged in to, what do you mean? The MEE server is a standalone server and not a member of the AD where the users are. How can I use the tool to retrieve from another AD?

      • Simon Hunt
        October 12, 2012 at 15:35

        You have to be working on a machine which is part of the domain to access the domain. You’ll have to run the script on a member machine.

      • Federico
        October 12, 2012 at 15:37

        Thanks… If I connect to a member machine and run the script from there, is there a way to tell the script how to connect to the MEE server and database?

      • Simon Hunt
        October 12, 2012 at 15:46

        For tech support, it’s simpler and more effective to use https://community.mcafee.com/community/business/data there are lots of posts on this subject.
        But to answer your question, you need to have a working EEM or client set up on the machine, as well as the API itself for the script to work.

  4. Darron Lightbourne
    December 15, 2009 at 08:46

    Thanks for the quick response. When I run the AddBinding command against ‘Tom’ the user was found and updated. When you say I don’t have the API installed, are you reffering to SBADMCL or something else that I could be missing? I checked the Endpoint Encryption Manager directory and there is an SbAdmCom.dll from the original installation. Do I need to regester it?


  5. Simon Hunt
    December 15, 2009 at 08:56

    It’s TOM in Windows AD, not Tom in EEM which is the problem. Yes, you always need to register a COM object somehow.

    Maybe you don’t have enough rights to get the GUID of the user TOM from AD? More likely there is no user called “TOM” though.

  6. Darron Lightbourne
    December 16, 2009 at 16:03

    Thanks for your help. I was not able to get the LinkUser.vbs script to work right for some reason but was able to change the bindings with the SBADMCL AddBindings command.

    Thanks again,


  7. gowtham
    November 15, 2010 at 03:43


    There is a problem in my safe boot console . After i sync the safeboot with LDAP, i can find some error lines (error adding user bhfsys 0xdb010008) – “The object already exists”). but the users are available in the console like alphanumeric numeric character “00000001.0000004f” .If i am right click on the user and select properties ,i am getting the error “Attribute not found” ….Can you pls help me on this …

    • Simon Hunt
      November 15, 2010 at 08:34

      Gowtham, this is not a place to get technical support. For that you should call your McAfee representative, or use http://community.mcafee.com

  8. Simon Hunt
    March 20, 2013 at 16:51

    I’m not sure what the link between the two is. You don’t need this tool to upgrade your DC.

  9. rodirebel
    March 21, 2013 at 10:56

    The problem is vbs script is far too complicated to redirect ldap connector from old DC to new DC? Is there any other way to accomplish this?

    • Simon Hunt
      March 21, 2013 at 11:00

      what’s complicated about the script? You just have to enter one command line.

      So, you’re not upgrading your DC, you are moving your environment to a new DC – There are three ways to do this, you can type the values manually into each user, you can use the API and write a script yourself, or you can use linkuser.

      OR you could ask Microsoft why moving to a new DC changes the GUID’s of the users.

      I suggest you post at https://community.mcafee.com/community/business/data – that’s where to get technical support, not my blog 😉

  1. September 3, 2009 at 14:22

Leave a Reply to Federico Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: