Pop, OpenSSO Account Lock(out) and Drop

The OpenSSO Authentication Service provides a feature where a user will be locked out from authenticating after a defined number of failures. (More information is in the Sun OpenSSO Enterprise 8.0 Administration Guide.) When account lockout is enabled an attribute in the user data store is used to hold information regarding the authentication attempts. This information includes:
  • invalid attempts count
  • last failed time
  • lockout time
  • lockout duration
Many businesses have user data stores already configured for their overall deployment. If this is the case, the administrator might not want to (or need to) load the OpenSSO schema. The following procedure can be used to configure the account lockout feature to write this information to an attribute not defined by the OpenSSO schema.
  1. Login to the OpenSSO console as the administrator; be default, amadmin.
  2. Click the Realm tab.
  3. Under the Authentication tab, click Advanced Properties.
  4. Select Login Failure Lockout Mode to enable account lockout.
  5. On the same page, configure Invalid Attempts Data Attribute Name.

    Invalid Attempts Data Attribute Name is used if the OpenSSO schema is not loaded. Set the value of this property to the attribute name of your choice and OpenSSO will store the data as the value of this attribute. Note that the attribute you specify needs to also be defined in the LDAP User Attributes property of the data store configuration if the data store type is either Active Directory, Generic LDAPv3 or Sun DS with OpenSSO schema.

    NOTE: Store Invalid Attempts in Data Store is selected by default and enables the storage of the data as the value of the sunAMAuthInvalidAttemptsData attribute in the user data store. In order to store data in this attribute, the OpenSSO schema has to be loaded.

Now for those who can lock it, pop and drop it with some old skool funk, Peace Pipe by B.T. Express.

Comments:

Hi Michael,
Reading the above article, it seems the OpenSSO account locking functionality is completely separate from any account locking capabilities built into your chosen User Store directory (let's take AD as an example).
So, if I enable OpenSSO account locking, and someone gets locked out of OpenSSO, they will still be able to login to their desktop (not OpenSSO integrated). In this mode, I must also load the special schema into AD.
On the other hand, if I have account locking enabled in my AD, then I'd expect that both desktop and OpenSSO logins would co-operate in sharing the AD account lockout capabilities - and the help-desk wouldn't need to know how to unlock an OpenSSO account; they'd just use the standard AD tools.
If my understanding is correct, then what OpenSSO features am I giving up by not loading the extra schema and letting AD do the account locking?

Thanks

Steve

Posted by Steve Kotsopoulos on July 09, 2009 at 01:29 AM PDT #

I share the same concerns as Steve. Any thoughts, Mike?

Posted by Paul Spinelli on September 23, 2009 at 06:23 AM PDT #

Sorry, Steve, I obviously missed the notification of your comment in my Inbox. Glad Paul caught it.

The schema contains account lockout attributes that are data store agnostic. If you don't load the schema you will not have account lockout functionality in OpenSSO. Then if AD locks out the user OpenSSO will throw some kind of generic error, not a lockout. Loading the schema allows for consistent behavior.

If you have other questions, try the users @ opensso alias. My knowledge of AD is pretty much nil. ; )

hth,
michael

Posted by Michael Teger on September 23, 2009 at 06:53 AM PDT #

Post a Comment:
Comments are closed for this entry.
About

docteger

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today