Novell Home

My Favorites

Close

Please to see your favorites.

SecureLogin data not saved in AD

This document (7011616) is provided subject to the disclaimer at the end of this document.

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.
 
 

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 TID 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.



 

Disclaimer

This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7011616
  • Creation Date:11-JAN-13
  • Modified Date:22-OCT-14
    • NetIQSecureLogin

Did this document solve your problem? Provide Feedback