See all insights
Apply 2FA on Windows AD logins, IIS, VPN, RDP & RD Gateway, Off-network and SaaS connections.
Choose between push notifications, hardware devices, or authenticator apps as MFA methods.
Secure access to cloud apps with SSO combined with MFA and context-aware restrictions.
Monitor, alert, and respond in real time to all user access activity.
Control how users access the network based on machine or device, time, session type or simultaneous connections.
Get centralized auditing across your network and report on all Windows user access events.
There is no way in Windows to limit a given user account from only logging on at one computer at a time.
In terms of interactive logins at desktops and laptops, a system administrator cannot prevent a given user from going up to one computer, logging on there, letting somebody work as him or just leaving the computer unattended, and then walking up to another computer and logging on there.
And the reason is because of the architecture of Windows: there is no entity keeping track of all the places where a user is logged on, as each workstation basically handles that individually.
Workstations have to talk to the domain controller, but the domain controller is only involved in the initial authentication. Once the domain controller tells the workstation that «Yes, this user is authentic» or, «No, he is not; his credentials were not good,» then the domain controller just forgets about that logon session. It does not keep track of the fact that the user still logged on at that computer. Each computer does that on its own. That is probably why there is no concurrent login control built into Windows in the first place.
Microsoft originally tried to address this major issue with an unsupported tool called Cconnect, provided in its Windows NT/2000 Resource Kit. However, due to the complexity to implement, the limited and poor functionality, the constraints and the additional flaws(!) the application actually generated, few and far between are those known still actually using it.
With the venue of Active Directory, Microsoft has been back to the drawing board; and whereas one would have thought that they would have properly addressed the issue, they are in fact back with another unsupported tool based on logon scripts, responding only partially to requirements and equally awkward to deploy and maintain: LimitLogin.
LimitLogin is indeed cumbersome to set up and use:
Finally, it requires distributing client packages that support communicating with the Web server via SOAP (a lightweight protocol for exchanging structured information in a distributed environment).
As an American friend of mine once told me: «LimitLogin looks like a Rube Goldberg's machine»…
Not controlling concurrent logins creates a whole accountability and non-repudiation issue.
That is why this feature is required for an Information System to comply with major regulatory constraints, including:
UserLock allows simultaneous logon (same ID, same password) limitation or prohibition, per user, user group or Organizational Unit.
A limit can also be set for the total number of sessions of all members of a group. This for example useful if each department of an organization is only allowed to open a limited number of terminal sessions on servers in order to fairly share resources.
Share this page:
Free number for US & Canada: + 1-800-492-3951
GMT +1: +33 5 59 41 42 20
© IS Decisions