Article ID: 114483, created on Jul 31, 2012, last review on May 10, 2014

  • Applies to:
  • Operations Automation

Table of contents:

1. General Information
2. Deployment
3. Implementation Details
4. Troubleshooting

General Information


In case Windows Shared Hosting module is deployed in POA and Microsoft Active Directory is used for storing information about service users it is possible to synchronize the user lockouts for both POA and Active Directory.

The user locked out in POA Control Panel will not be able to login to any hosted service like OWA. And vice versa, the user locked out during login attempts to the hosted service will also be locked out in POA Control Panel.

Service users locked on either side (POA or AD) will be shown in POA Provider Control Panel at System Director > Audir Manager > Locked Users like on the screenshots below:

  • User locked by Active Directory:
  • User locked by POA

On the same screen POA Provider may unlock the user. When the user is unlocked manually or after the locking period is over, they can login again to POA Control Panel as well as to any hosting services provisioned by their subscription.

 Notes:
  • If a user was locked in Active Directory then the 'IP address' field will contain value 'Unknown'.
  • The 'Unlock on' field shows when the user will be unlocked.
  • 'According Active Directory Settings' in the 'Unlock on' field means that POA does not know the exact locking period. User will be unlocked according either to AD or POA settings.

Deployment


To make user lockouts synchronization work the POA package ADLockoutMonitor should be installed on all AD Domain Controllers in the hosted environment. Follow instructions in POA Provider's Guide > Installing Package on Host.

During the package installation one may set the time period the service will check the locked and unlocked users in AD and synchronize the new states with POA. It is stored in the HKLM\Software\SWsoft\PEM\ADLockoutMonitor\CheckPeriod registry key on all AD Domain Controllers where POA package ADLockoutMonitor is installed. The default value is 60 seconds.

It is strongly recommended to bring to correspondence the POA and AD user lockout policies. The table below shows the correspondence of POA and AD policy names.
POA Policy Name AD Policy Name
Failed login attempts checking period Reset Account Lockout Counter After
User locking period after too many authentication errors Account Lockout Duration
Maximum authentication attempts before locking user Account Lockout Threshold

Follow the steps below to enable brute-force attack protection and configure its parameters in POA:

  1. Log into POA Provider Control Panel
  2. Go to System Director > Configuration Manager > System Properties.
  3. Click Edit.
  4. Enable the Password brute force attack protection option.
  5. Configure the parameters for this option:
    1. Failed login attempts checking period (minutes) - specify the period in minutes, during which the system counts login failures from the user’s IP address(es).
    2. User locking period after too many authentication errors - specify the length of the temporary lock-out period in minutes.
    3. Maximum authentication attempts before locking user - specify the number of sequential failed login attempts after which POA locks the user.
  6. Click Submit to save the changes.

Note: Since user identification is based on IP address, a locked user can by-pass the access restriction by logging in from a different IP address.

To change the Active Directory user lockout policy settings, refer to the POA Windows Hosting Infrastructure Deployment guide > Configuring Account Lockout Policy.

When the POA package ADLockoutMonitor is installed on the AD Domain Controller the following changes will be done:
  • The system service ADLockoutMonitor.exe will be added to the Windows (it runs under pem_admin domain account)
  • Scripts ADLockoutConfigure.vbs and ADLockoutDB.vbs will be stored in the folder C:\Program Files (x86)\SWsoft\PEM\bin
  • Microsoft Access database file will be created in the folder C:\Program Files (x86)\SWsoft\PEM\data\ locked_users.mdb

Implementation Details


In general AD Lockout Monitor works this way:

1. An user tries to log into Windows-hosted service such as Exchange mailbox, supplying correct username and incorrect password. The password is being checked against information on AD Domain Controller.

2. The user is being blocked by AD on that Domain Controller, and AD Lockout Monitor detects this situation. AD Lockout Monitor stores such blocked users in its own local database.

3. From time to time (determined by the HKLM\Software\SWsoft\PEM\ADLockoutMonitor\CheckPeriod registry key on the Domain Controller), AD Lockout Monitor dumps its local database to POA, populating the list of blocked users.The synchronization of lists of blocked users among Domain Controllers is done by AD replication. AD Lockout Monitor service does not interact with all Domain Controllers, it works with the Domain Controller where it is installed.

Notes:
 
  • The Windows service ADLockoutMonitor periodically looks for currently locked users in AD.
  • The list of locked AD users is stored into local Microsoft Access database locked_users.mdb for optimization.
  • The list of newly locked users, as well as list of just unlocked users, is reported to POA Management Node by CORBA call to ActiveDirectory Service Controller (full list or just diff).
  • Users in AD and POA are matched by samAccountName.
  • When a service user is locked in POA (after several failed attempts to authenticate in POA MyCP), POA disables the appropriate user in AD.
    • If single service user has services in different Windows domains, all corresponding AD users are being disabled.
  • When a service user is unlocked in POA then POA unlocks and enables all corresponding users in AD.
  • POA periodic task 'Check and unlock users' unlocks users who was locked until ‘Unlock On’ time.

Troubleshooting


If the list of locked users in POA Control Panel is not being populated with actually locked AD users follow the steps below to troubleshoot the problem:

  1. Make sure that the POA package ADLockoutMonitor is installed on all AD Domain Controllers in POA-managed infrastructure.
  1. Make sure that the Windows Service ADLockoutMonitor isrunning on AD Domain Controllers.
  1. Check if POA system properties described in the Deployment section above in the article are configured properly.
  1. Check that Active Directory user lockout policy settings are in sync with those of POA.
  1. If user was locked in POA and was not locked in AD the check if the background task with name Set properties for AD entity 'john.doe' of type 'UserAccount' (entity_id: 830) exist in POA and was successfully completed when the user was locked in POA. This task is going to lock the user in AD.
  1. If user was locked in AD and was not locked in POA check if the ADLockoutMonitor service correctly detected locked user, try to find the lines like this in POA Agent log file C:\Program Files (x86)\SWsoft\PEM\Logs\poa.debug.log on AD Domain Controllers:Jul 31 08:53:39 DC01 : DBG [SYSTEM 4:3176:8f4 lib]: [ADLockoutMonitor] It's time to looking for locked users in Active Directory. Jul 31 08:53:39 DC01 : DBG [SYSTEM 4:3176:8f4 lib]: [ADLockoutMonitor] Current DC: dc01.hosting.local. Preferred DC: DC01.hosting.local
    Jul 31 08:53:39 DC01 : INF [SYSTEM 4:3176:8f4 lib]: [ADLockoutMonitor] Starting search. Filter: (&(objectClass=user)(lockoutTime=*)(lockoutTime>=129881726199296875)), Path: LDAP://OU=Provider,DC=hosting,DC=local
    Jul 31 08:53:39 DC01 : DBG [SYSTEM 4:3176:8f4 lib]: [ADLockoutMonitor] user john.doe is locked at 2012.07.31 01:53:01
  2. Check if POA Management Node received notification from ADLockoutMonitor service about locked user, try to find the entries like shown below in the log file poa.debug.log on POA MN:Jul 31 15:04:45 pa-poa : DBG [4:3176:8f4:1226 1:22525:b6f00b90 UIManager]: [txn:543778 LoginRestrictions::LoginRestrictions_impl::onLockExternalUser] user was locked in external system: user_id = 576, locked_time = 1343700274

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF