Why Active Directory Logon Controls Simply Aren’t Enough

Through Active Directory, administrators can assign and enforce the security policies of the entire domain and manage them from a central location. A big part of dealing with both external and internal attacks is tracking logon activity. Most organizations need to work on increasing log on control measures and proactively tracking the logon activities of all users. However, Active Directory logon and logoff controls have some major limitations which make this process more complex than it needs to be…

1. You cannot control logon activities based on Groups and OUs

You cannot implement logon time and workstation restrictions based on Groups and Organizational Units. If you want to implement such restrictions, you will have to do it based on users in “Active Directory Users and Computers”. After you have applied these restrictions, the user will not be allowed to logon in the banned time interval. The user also cannot logon at selected computers. You cannot implement such restrictions based on OU and Groups.

2. You cannot determine the initial access point in a nested session

Let’s suppose that you have started a series of computer accesses from an endpoint that ultimately resulted in nested sessions. If you have to find out the initial access point, starting from the end or anywhere in the middle, there is no way to determine the initial access point or the location from where you started the sessions. Yes, Event Viewer records every logon, but going through it is like looking for a needle in a haystack (to use a tired expression). You cannot get this information quickly. This could be a problem if a security concern or compliance mandate requires such reporting.

Lepide Active Directory Auditor, with its real-time alerting and meaningful predefined reports, allows you to extract the information required in seconds.

3. No way to force a logoff after the sanctioned logon time expires

You can control when a user logs on at the computer, but what about the cases where a user has remained logged on at the computer over the allotted time span. For example, let’s say a user usually logs on to his/her computer between 9:30 AM to 6:30 PM. One day, however, that user logged on at the computer at 4:00 PM and continued working beyond 6:30 PM. Will Active Directory logoff at 6:30 PM? – NO.

Active Directory can control when users can logon (and prevent logon outside allowed hours), but it cannot log them off in the middle of their sessions. You can write a script and create multiple schedules to force a logoff after the allotted time expires, but that is a workaround, not a dynamic answer to the problem.

4. It does not show the previous logon time while you are going through Windows Server or Active Directory

Same as in our last example, whenever you logon to your bank account, it shows your previous logon time. Showing the previous logon time ensures that you know if somebody else is logging into your account. It is also a must for NIST 800-53 compliance – which provides the security controls’ catalog for all US-based Federal Information Systems (except those which are related to national security).

5. No provision of time-limited control

Let’s say you want to add a user to a particular group for a particular time interval after which the user should be automatically cast-off from the group. There is no dynamic way to ensure this facility, except through a mix of scripts and scheduled tasks.