Identity Management and the Administrator’s Account

When multiple users have access to a generic account (for example the default Administrator account), it can be difficult, even impossible to identify the actual person using the account. Identity Management (or IDM for short) is one of the challenges that IT managers need to face in this ever changing environment, and with plenty of security and compliance issues at hand, failing to properly manage identities of users and service accounts can cause some great headaches.

Imagine working in a datacenter that hosts tens or even hundreds or web servers. In that site, you’ve got many users that are all using the same user account credentials – “Administrator” – and all are logging on locally to perform their daily administration tasks. Even if there are just a handful of users accessing these machines, it will still be very hard for you, as the person in charge, to really know which one of these administrators has logged on to which system.
Finding out “who touched the server” and “who did what” is critical when you’ve got a situation at hand. For example, you are awaken by a text message on your cellular phone, telling you that a particular server has just stopped responding, or that a specific service is no longer running. The first thought that comes to mind of any IT administrator in that case is “who touched this server”. In most cases, you remotely connect to the system (if you can), and look around. You can see something is wrong, and in some cases, you may even be able to what is wrong. However, when all the privileged users use the same user account you may now know exactly who did it.
True, you can argue that no decent organization lets many users use the same user account. However life and experience teaches us that not all scenarios are made equal. More than once I came across well-managed networks that were properly protected and with all the right security measures in place, but nevertheless lacked some basic aspects of security infrastructure management.
You can prevent the entire issue from happening by making sure that the administrator’s account password is only known to the one person that needs to know it. Other administrators or power users should not have knowledge of this password. However, as noted above, there are many cases where this is simply not possible. For example, scenarios where a large web server farm is not configured as a part of an Active Directory domain, and all access to these machines is done via the built-in Administrator account.
So far, answering this challenge has been difficult, often impossible. One solution for this problem is to ask the user for their identity. This approach will let the user log on to the Windows desktop by using the username and password they already have. Once logged on, but prior to getting their desktop, the user(s) will be asked to provide additional secondary logon information.
One such system is ObserveIT.
As you know, I work for ObserveIT (www.observeit-sys.com), a company that has an amazing recording software that allows you to know who touched your servers, what did they do, what did your privileged and external vendors change on my servers and more. ObserveIT’s product allows enterprise-wide recording and indexing of any human interaction with the servers, and what makes it so awesome is the fact that it indexes this data alongside with detailed metadata of what is seen on the screen, allowing full searches within the database. I’ve written more about ObserveIT’s recording capabilities in my Record and Audit Terminal, Citrix and RDP Sessions – ObserveIT Product Overview article.
One of the coolest features of ObserveIT is what we call “Identification Services”.
By using ” Identification Services”, we will first identify the specific generic user accounts that we need to positively identify. These users are called “Forced-Identification” users. In this example, I’ve configured the built-in “Administrator” account to be a “Forced-Identification” user.

Next, you can link ObserveIT with one Active Directory domain or more. These are called “LDAP Targets”, and they are the place where ObserveIT looks to see if the user credentials that were presented during the secondary ObserveIT logon screen are correct. The cool part is that ObserveIT can query this AD domain even if the servers or workstations that are being monitored are Not members of that domain. This means that a server farm that is all part of one workgroup can still be used. All you need to do is to point the ObserveIT server to the right Active Directory domain, and it’ll do the rest for you. In the above example, I’ve used an Active Directory domain called OIT-DEMO.LOCAL.
Whenever a Forced-Identification user logs on to any ObserveIT-monitored server or workstation, the user will first enter their credentials in the regular Windows logon screen prompt.

Note how in this example, the server is NOT a member of any AD domain, and the user logging on is the built-in Administrator.
After passing that authentication phase, the user will be displayed with a secondary ObserveIT logon screen.

Note that the user can authenticate against the OIT-DEMO.LOCAL domain even though the computer is not a member of that domain!
Now, by looking at the Server Diary, User Diary, Free-Text Search or Reports – you will be able to clearly see who exactly has logged on as the Administrator, while before implementing Identification Services, the only information you had was the Windows user name.

A second scenario where the ObserveIT Identification Services is important, is the ability to only allow users that are members of a specific Active Directory group to log on to the monitored machines. When using this scenario, you will be able to restrict users from gaining access to the Windows desktop, unless they are members of a pre-defined Active Directory group. By default, all groups can authenticate, but you can either exclude specific groups from being able to authenticate, or disable all groups and only allow specific groups to authenticate.
For example, in a domain called OIT-DEMO.LOCAL, all users can authenticate in the ObserveIT Identification screen, except users that are members of the NO-OIT-LOGON group. In Active Directory Users and Computers, create the group and add members to it.


When a user logs on to a monitored server by using the Administrator account he or she will be presented with the ObserveIT Identification screen. On that screen, if they type USER1 or USER2, they will not be able to gain access to the desktop, because these users are members of the NO-OIT-LOGON group.

So, by using the “Identification Services” built-into ObserveIT, you can not only positively identify who used specific generic user accounts such as the “Administrator” account, but also prevent access to the system if the user logging on is not a member of a specific Active Directory domain.
You can get ObserveIT for free! Just download the Xpress version below:
ObserveIT – download free Xpress version
www.observeit-sys.com/products/xpress.asp