Accounting information such as when the role was locked, why it was locked, and who locked is stored in syssrvroles, and can be useful for role locking accounting.
There are several reasons roles may be locked:
Entering the wrong role password a specified number of times. 'max failed_logins' option can be associated with roles during their creation or alteration. It specifies the number of failed role activation attempts after which a role is locked.
Manually locking the role using alter role:
alter role rolename lock
Adaptive Server includes these columns in syssrvroles for lock information:
lockdate – indicates when the role was locked.
locksuid – indicates who locked the role.
lockreason – gives a reason why it was locked. This is in the form of codes:
Values for lockreason |
Value for locksuid |
Description of lockreason of role |
---|---|---|
NULL |
NULL |
Role is not locked |
1 |
suid of caller of alter role |
Role locked by suid by manually executing alter role rolename lock |
2 |
suid of user whose last attempted role activation led to the role getting locked |
Role locked by Adaptive Server due to failed role activation attempts reading max failed logins. |
The system security officer can use alter role to manually lock or unlock a role. For example:
alter role physician_role lock alter role physician_role unlock
Information about the lock status of a role is stored in the status column of syssrvroles.
See alter role in Reference Manual: Commands.
In high-availability environments, these syssrvrole columns
are updated on both the primary and secondary servers.