SecureLogin data not saved in AD

  • 7011616
  • 11-Jan-2013
  • 05-Dec-2014

Environment

Novell SecureLogin
NetIQ SecureLogin
NSL 7.x
NSL 8.x
AD mode
Active Directory as data store

Situation

User prompted to setup passphrase each time SecureLogin is launched.  Passphrase not saved.

"BROKER_ACCESS_IS_DENIED(-372) error returned after entering credentials when prompted during initial execution of an Application Definition.

Credentials captured on the workstation show in manage logins, but not in AD.
SecureLogin data is not written to  Active Directory.
Users cannot save SecureLogin credentials to AD, but can save changes to the local workstation.
Changes made on one workstation are not present when user logs on to a different workstation.
 
Manage Logins shows stored credentials on the workstation on which they were captured, but not on a different workstation, even though both AD and the local file are available (as shown in the SecureLogin "About" dialog).

Protocom-SSO-Auth-Data attribute shows as “not set†in Users and Computers, properties of the user, “Attribute Editor†tab. Other Protocom-SSO-* attributes exist and have values as expected.


Resolution

Resolve problems with Active Directory permissions.
 
In this case the problem was solved with the AD “Users and Computers†utility by checking the box for “Include inheritable permissions from this objects parent†on the “Permissions†tab in “advanced Security Settings†in properties of the user.
 
 
IMPORTANT NOTE:  If setting "include inheritable" on a group, use a group other than "Domain Admins" or another protected group.  If this setting is made on a protected group, it will be removed by Active Directory within an hour.  The Microsoft Technet article at http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx  provides a list of protected groups, and in the third paragraph states the following:
....the default behaviour is that inheritance is disabled on these privileged accounts, ensuring that permissions applied at the parent level aren't inherited by the protected objects, regardless of where they reside. Finally, the background process running every 60 minutes identifies manual modifications to an ACL and overwrites them so that the ACL matches the ACL on the AdminSDHolder object.



Additional Information

 In this case users had “read†permission but not “write†permission to some of the Protocom-SSO-* attributes.  SecureLogin users must have both read and write permission to all six Protocom-SSO-* attributes as shown:
 
 
 

If including inheritable permissions does not resolve the problem, the following might help:

  1. Rerun ADSchema.exe and when prompted for the place to assign rights point directly to the problem user.

  2. Rerun ADSchema.exe on a primary domain controller while logged in as THE Administrator.
  3. Delete the user's SecureLogin configuration in the management utility (shown below), then delete the users' local cache as described in “Fix 1†of KB 7006706 , and have them start over with SecureLogin. Where to delete the users's SecureLogin configuration:

     4.  Delete and recreate the users in AD.  

Note: The "auth-data" attribute should always be set when a user has been activated for SecureLogin. This attribute is used to encrypt and decrypt SecureLogin data.  With "auth-data" not set,  SecureLogin would not be able to encrypt or decrypt data, and therefore not be able to read or write to the directory.  When passphrases are used the value of this attribute is based on the passphrase; in environments where the passphrase is not used, it is based on the user name.