Managing the performance impact of OID last login tracking

Does your environment have demanding performance requirements? High volume, customer-facing applications such as eCommerce or Internet banking, with business critical requirements for low response time?

Then having last login tracking enabled in OID (orclpwdtracklogin=1 in your password policy) can have a substantial performance cost. It converts every login, every bind/compare against an OID entry, into a modify of that OID entry to update the last login time attribute. This substantially increases the write/commit load on the database and the storage layer. It also substantially increases replication traffic in replicated environments. On that basis, you should seriously consider disabling it.

Here’s an example of how to check your OID password policies, to see if orclpwdtracklogin is enabled:

> $ORACLE_HOME/bin/ldapsearch -h localhost -p 3060 -D “cn=orcladmin” -w PASSWORD -b “” ‘(objectclass=pwdpolicy)’
displayname=Password Policy for Realm dc=example,dc=com

This search will return multiple password policies – for brevity, I’ve only shown the first one above. Once you’ve identified a policy with login tracking enabled, you can turn it off as follows:

> $ORACLE_HOME/bin/ldapmodify -h localhost -p 3060 -D “cn=orcladmin” -w PASSWORD
dn: cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com
changetype: modify
replace: orclpwdtracklogin
orclpwdtracklogin: 0

modifying entry cn=default,cn=pwdPolicies,cn=Common,cn=Products,cn=OracleContext,dc=example,dc=com

What if you have a security requirement to keep track of last login times?

Explore whether there is somewhere else in the stack you can meet this requirement, other than in OID. For example, if you are using OAAM, then OAAM will be keeping track of last login information, and you don’t need to track it separately in OID.

And since this is controlled at a per-password policy level in OID, it is possible to have it turned on for some users, and turned off for others. For example, if all your end-users are having their logins tracked by OAAM, you don’t need to track last login information in OID. But if you have system administrators who on occasion log in to OID directly, you might still need to have OID track their last login times. So, you can have one OID password policy for normal users, which disables last login tracking; and another for system administrators, which keeps it on.

What about service accounts used by applications to access OID?

With normal user accounts, you might have five logins happening at the same time, but each of those logins will be as a distinct user account. For service accounts, however, it is not uncommon for there to be numerous concurrent logins into the same service account – for example, if one of your applications runs on a five node cluster, and if each node establishes an LDAP connection at the same time, that could be five concurrent logins to the same service account. With login tracking this will result in multiple concurrent updates to the same LDAP entry, hence multiple concurrent updates to the same database row. With RAC, these updates might end up on different RAC nodes, with the result that multiple RAC nodes are contending for the same database row. So the negative performance impact of login tracking can be far worse than that for end-user or system administrator accounts. For these reasons, having OID last login tracking turned on for service accounts is not recommended. Given the frequency of logins to these accounts, it has limited security value.

Add Your Comment