UserLock advanced documentation 1. Agent deployment with msi package or with the UserLock deployment module The UserLock deployment module doesn t deploy the msi package. It just transfers the agent file (250 KB for a 32 bits computer) and register it on the remote computer but the agent is not registered as an application (in Add/Remove programs). So if you want to uninstall it you need to do it either from the UserLock console or by hand (see http:///en/software/userlock/faq.cfm#29). In addition, the msi package registers the agent as an application in Add/Remove programs. So typically if you install the agent with the msi package and you uninstall it with the UserLock console the agent will be unregistered and will no longer be loaded at the next reboot but you will still see the UserLock agent entry in Add/Remove programs because the UserLock deployment module doesn t uninstall the msi package. So if you want a clean uninstallation you should rather uninstall the msi package from add remove program. This can also be done silently with the following command line: MsiExec.exe /x{effb3e74-ff2d-40dc-8848-5c9633599a49} /qn How does the automatic deployment mode act with computers for which the agent was installed by using another way (either with the msi package or prebuilt in the computer)? UserLock is also able to recognize an agent that was not deployed by its deployment module. So if the automatic mode is started the agent will not be installed again except if the server has a newer version. In this case the server will automatically upgrade the agent to this new version. Can the UserLock server upgrade an agent that has been installed with the msi package? Yes this is possible. However the agent version indicated in Add/remove programs will not be updated but the agent version indicated in the console will be accurate. 2. Bandwidth consideration about the computer polling done by the UserLock deployment module The UserLock deployment module only checks computers one by one. During the first pass after service startup UserLock waits 100 ms between each computers. In further passes UserLock waits half a second between each computer. In consequence, with a big network the UserLock deployment module will not take more bandwidth but will rather use more time to check all computers. If the automatic mode is not started a computer check will take 3 KB in both way and you can expect 15 KB/s during the first pass and 5 KB/s in further passes. If the automatic deployment mode is started a 250 KB file will be transferred to any workstation without the agent. So in the worst case UserLock would use 2.5 MB/s of bandwidth during the first pass or 500 KB in further passes. These values will never be reached because the network time response slow down the process, because there is usually some workstations that are powered off and because the agent may already be installed on many workstations. To approach the worst situation you need to restart the UserLock service and immediately enable the automatic mode and the agent should not be already deployed on any workstation. So in order to use as little bandwidth as possible the automatic mode should be started when the UserLock
service is already started since a while and when the agent is already deployed through another way on most workstations. Doing so, the used bandwidth will be negligible. 3. UserLock SQL database and session database How to configure the connection to SQL server with custom settings If you need some specific connection settings with your SQL server (e.g. change the port number) you can t use the simplified database wizard provided with UserLock. You will need to configure your connection with the standard ODBC wizard. Figure 1 Select ODBC wizard in the database wizard Figure 2 Select Machine data Source and click on New
Figure 3 Select System Data Source Figure 4 Select the SQL server driver
Figure 5 Select the name of the data source and the name of the SQL server Figure 6 Click on client configuration
Figure 7 Unselect Dynamically determine the port and enter the correct port number Figure 8 Select the UserLock database as default database The data source is now created and you can click OK until you come back in the UserLock server properties with the updated connection string. Then click Apply and click on create table to create the UserLock table in the database. Role of the SQL database The SQL server database is only intended to keep the logon history and is never queried by the UserLock server. Without SQL database a UserLock would still be able to maintain the protection.
So where sessions displayed in the UserLock console comes from? What we call the session database is kept in memory and saved each minute in a file named userlock.cfg located in the UserLock installation folder. So each time an agent notifies a logon event to the UserLock server the session database is updated in memory and after maximum one minute saved on the disk. If for any reason the service needs to be restarted the session database persists and is reloaded in memory through the userlock.cfg file. The session database is an image of all currently opened sessions and is updated in real time. UserLock will query the session database in memory in order to know if a user is allowed to logon. So there is no SQL query in order to know if a user already has a session open. This is done through fast memory accesses. 4. Permissions requirements Rights needed by the UserLock Service account 1- The UserLock service account needs administrative rights on the local server for the first execution. Later you can remove administrative rights without any major losses in functionality. You just will not be able to install the agent locally from the console or logoff the local session from the UserLock console. If the UserLock service account doesn t have administrative rights on the server you need to grant to him full access to the following locations. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ISDecisions\UserLock (x64 machines) HKEY_LOCAL_MACHINE\SOFTWARE\ISDecisions\UserLock (x86 machines) C:\Program Files (x86)\isdecisions\userlock (x64 machines) C:\Program Files\ISDecisions\UserLock (x86 machines) 2- To get all features working the UserLock service accounts needs administrative rights on all computers to protect. This is not a need but without it the following features will not work: UserLock will not be able to deploy the agent and you will need to use another way to do it. The agent status will be updated in degraded mode (uninstall status not updated) The recovery of lost logon events will be done in degraded mode Agent communication settings will not be updated on clients if a backup server is added or if one of the UserLock services is moved to a different physical server. You will not be able to remotely close sessions from the console or web console The option allowing users to logoff their previous session will not work Unable to remotely reboot the workstation from the console 3- The same rules apply for the backup server but in addition if the service account of the backup server is not administrator of the primary server you need add it in the UserLock administration permissions (with full permissions) in order to allow the synchronization to work between both servers. Rights needed by the client computer account The agent runs on the client as the localsystem account. In order to be able to communicate with the server without any problem the localsystem account should be identified on the UserLock server by its domain computer account (MACHINENAME$). This is normally the case in an AD environment. If for any reason the localsystem account cannot be authenticated as its AD computer account the agent will downgrade in user communication mode. He will communicate with the server in behalf of the user only when a user open/lock/unlock/close a session. In this mode some features will not work. The agent will not be able to update its status on the server after a restart of the workstation, unexpected shutdowns will not be notified to the UserLock server to clean ghost sessions and unsent session events (after network failure) will not be sent to the server. So if all agents are in downgraded communication mode the UserLock session database correction process will entirely rely on the UserLock server computer polling in order to recover lost session events from workstations. How is the session database reflected on the UserLock console?
The console sends a command to the UserLock server to get the list of all opened sessions and display them. In order to update the view the administrator need to click on refresh. There is currently no automatic refresh of the user session view on the console by polling the server. 5. Logoff technology The logoff of a session by UserLock is done by copying an executable on the remote computer through administrative share ADMIN$ (LogoffAgent.exe 140 KB) and the executable is then started in the user session in order logoff the session. 6. Synchronization between the backup server and the primary server When the primary server is running the UserLock backup server is never contacted by clients because the UserLock agent will always try to contact the primary server first and contact the backup server only if the primary server can t be contacted. So a backup server is designed for failover but not load balancing. When the primary server is online the backup server just maintains its session database up to date by synchronizing with the primary server. The synchronization is differential. This means that both servers synchronize all logon events that occurred since the last synchronization. If the backup server was just brought online the whole database session is not synchronized. Only new logon events will be synchronized. So there will be a difference between the session views on both servers. Both servers will display exactly the same sessions only after a while when sessions opened before the backup server was brought online will all be closed. 7. Workstations polling by the UserLock server The UserLock service poll a workstation just by checking some registry entries remotely. The agent creates a volatile registry key where specific information about the agent status is stored: The agent status The agent version Current sessions on the workstation Figure 9 Example of the volatile key created by the agent
The key allows the server to easily check if an agent is running, get the version of the agent, check if a session still exists. So the agent version displayed in the console should be accurate because it s the version number provided by the agent. If several agent version numbers are displayed in the console it would mean that the UserLock server was upgraded or the msi packaged agent doesn t match the agent on the server. The server will also get the content of the file c:\windows\system32\ulagent.log (through the ADMIN$ share) in order to retrieve all unsent logon events. If the agent server is working fine this file should be empty. 8. Agent server communication The agent contacts the server through named pipes (File and printer sharing TCP 445). The agent contacts the server just after a startup to send its status, and at each session event (logon/logoff/lock/unlock) to get approval and update the session database on the server. If for any reason some session events could not be sent in real time the agent will try each minute to send them again to the server until it succeeds. This is not a polling and doesn t take much bandwidth because while the connection fails no data is transferred and once the connection succeed the agent stops trying to contact the server as there will be no longer unsent events to notify. The agent also uses the ICMP protocol (ping) to check if the server is available. If the server doesn t answer to the ping the agent will try to contact another server (e.g. the backup server). 9. Performance and load balancing There is currently no load balancing feature in UserLock. If a network is too big to be protected by a single server the network need to be split in several protected zones (OUs or domains) and these zones need to be protected separately with different primary servers. Protecting a network with 30000 clients with a single server requires a dedicated server dual core 3 GHz 2 GB memory. Also read the following page in particular about the disk space requirements for the SQL server: http:///help/userlock/english/default.htm#requirement.htm Be also aware that 20000 clients on a single server is the most that has already be done.