Troubleshooting McAfee EE / SafeBoot SSO

This post was previously released under a different blog and is being republished by me below. That site is no longer available. I am the original author.

I wrote this tip for the McAfee Community back in November 2008 and thought it would be useful to post here. I do not work for McAfee or for SafeBoot and I’m only posting this because I documented it all out when I was having trouble so that I could fix it in the future and thought it might help someone else. You should complete the steps on a test or proof of concept system and you should always backup any files or registry keys before modifying or deleting them. This information is posted by me alone and does not represent the thoughts of McAfee, SafeBoot, or my employer.

1. Check Console Options
Ensure that the proper options are enabled in the console and that the changes have been synchronized with the client. These are the “set safeboot password to windows password” option as well as the option that the safeboot and windows username should be the same.

2. Verify your ClientDir folder.
This is in the registry under “HKLM\Software\SafeBoot International\SafeBoot\SafeBoot Device Encryption”. The ClientDir string should point to the folder that SbClientHelper.exe is located in. If you’re using MiniAdmin on your machines, this may change your ClientDir folder, which in turn breaks SSO Password Synching.

3. Enable GINA Tracing & Check Control IDs.
If SSO is working after you login to Windows properly once, this part is *probably* ok, and perhaps even worth skipping or moving to the end of your testing, but worth a quick check. Under your SafeBoot programs folder, open SbGina.ini and modify the “Trace.LogonWindowInfo” line to be YES. Take note of what the Trace.FileName is. If you’re missing these lines, they should be in the “GLOBAL” section and look like this:

The next part gets a bit complicated the first time, but it’s not that difficult. If the file LOGONWND.TXT already exists in your SafeBoot folder, rename or delete it. Now reboot and login as normal. The LOGONWND.TXT file will be created or recreated. Open that file with a text editor and you’ll see it’s basically a text based representation of your login window. There might be a few different windows there, so make sure you have the right one based on the title. Make note of the ID numbers associated with the username and password fields. Not that actual one for the labels (called “Static”), but the Edit boxes. An example:

Here you can see that the control IDs for the text box where someone would put their username is 1502, and the text box for the password is 1503. You also see the Class Number for the window is 32770. Write those down. Before changing your SbGina.ini file, you should probably back it up (although if you delete it a fresh copy should come from the server on your next synch).

Now, open up the SbGina.ini file on the client and find the section for your operating system and GINA. For example, using Windows XP and the MSGINA, the section would be “[MSGina.XP.LogonDialog]“. Under that section, you’ll want to make sure that the Dlg.CtrlID.UserName and Dlg.CtrlID.Password along with the Window.Class all match what you found in the logon dialog.

If all that looks good, you can repeat the same steps for the IDs when you lock your computer, and those would be under MSGina.XP.LockedDialog (for XP with the MSGINA).

4. Verify the SafeBoot Network Provider is Setup
This is an easy step. Open the registry editor, navigate to “HKLM\System\CurrentConsoleSet\Services\SafeBootNP 5\NetworkProvider” and make sure that there is a string there named “ProviderPath” and that the file it points to (by default the SbNp.dll file in the System32 folder) is right and that the file exists.

5. Use the File Monitor to Check SafeBoot
This step basically checks if any errors are returned when SafeBoot is trying to update the local database with your new password. First, get FileMon (all over the Internet, Google it – it’s free). Once it’s capturing, go ahead and change your password. Once the password change is complete, hit the picture of the magnifying glass in FileMon to stop capturing.

Next, use Edit->Find to search for “safeboot”. You should see that mpnotify.exe is the process that’s using these files. Go through the SafeBoot paths down the list looking at the results column. If any of them are anything but “success”, then you might be able to see what files are missing. You can ignore any errors about files ending in “.manifest”, these are expected. It might also be worth while to look at the files accessed by “SbClientHelper.exe” to make sure there are no problems there, you can always ignore the “NO MORE FILES” result.

It was actually this fifth and final step that actually resolved the issue for me, although all the steps before it were important for me to go through and learn how the product was working programatically.

FacebooktwitterredditpinterestlinkedinmailFacebooktwitterredditpinterestlinkedinmail

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.