Win 2003 server : Deny logon session on more than one workstation
I have a win 2003 domain server with 4 winxp workstations, I'd like to know how I can deny logon more than one session for users. I don't want user to logon a workstation and logon an other workstation at the same time with the same username and password, please help me,.
I have a win 2003 domain server with 4 winxp workstations, I'd like to know how I can deny logon more than one session for users. I don't want user to logon a workstation and logon an other workstation at the same time with the same username and password, please help me,....Thanks
Participate on our website and join the conversation
This topic is archived. New comments cannot be posted and votes cannot be cast.
Responses to this topic
Looks like you will really like LimitLogon, a free resource kit tool that will be released soon from Microsoft (the beta just concluded a few weeks ago).
Here are some Q&A about LimitLogon (from www.bink.nu):
LimitLogon Frequently Asked Questions
Q1: Will LimitLogin work with Windows 95/98 client machines?
A: No. LimitLogin supports the following operating systems:
* Windows 2000 Professional Service Pack 4 and above
* Windows 2000 Server Service Pack 4 and above (Including Terminal Server sessions)
* Windows XP Professional Service Pack 1 and above
* Windows Server 2003 (Including Terminal Server sessions)
Q2: Do I need SQL Server or any other type of database for LimitLogin to work?
A: No. LimitLogin uses your Active Directory database. It creates an Application Directory Partition on a Windows 2003 Domain Controller in the domain(s) you wish to use the application.
Q3: What level of Security does LimitLogin offer to effectively limit user logins in an Active Directory domain?
A: 'LimitLogin' offers better security model than previous tools such as 'CConnect', yet the current model in version 1.0 grants users read/write permissions on their own logins data attribute, thus leaving the possibility for malicious users to modify their own logins data (there is no possibility for users to modify their own logins quota or any other parameter). In addition, users can not temper with any other domain user's logins data other than their selves, and they cannot change anything else in the Application Directory Partition. You can also add further security by configuring LimitLogin to use SSL or IPSEC to prevent man-in-the-middle type of attacks. For more information, see the "Advanced Configuration Topics" page in this help file.
Q4: Is LimitLogin Supported by Microsoft?
A: No. Similar to the status of the resource kit tools and/or the support tools, LimitLogin is not officially supported by Microsoft (See the End User License Agreement in the \program files\LimitLogin directory). However, the MS field engineer(s) that wrote LimitLogin will make a best effort to help customers and partners to effectively use this product.
Q5: Do I need to switch my Active Directory Forest into Windows 2003 Forest Mode for LimitLogin to work?
A: No. LimitLogin is not dependant on your Active Directory Forest or Domain modes. It merely needs one Windows 2003 Domain Controller in the domain(s) you wish to use the application. Note that the Domain Naming Master FSMO Role needs to be running on a Windows 2003 Domain Controller in order to be able to create an Application Directory Partition.
Q6: I don't necessarily need to limit user logins. Can I use LimitLogin just to capture login data for managing my Active Directory environment more effectively?
A: Yes, you can. You can configure all users in the domain to have a relatively high login quota and simply let the scripts do their work of up[censored] your logins data, without reaching the quota that was set. The UI tools allow you to set the login quota up to 10 logins per user. You can use the sample script code under \program files\Limitlogin\Bulk_LimitUserLogins.vbs to set the logins quota to any value you desire. You can also scope this script to an Organizational Unit level. The default script runs on all the user accounts in the domain.
Q7: Some users don't log off properly (e.g. Hibernate their machines) and when they log in again they are automatically logged off due to their quota limit. How can I correct this?
A: The number of logins that the user has made is determined by counting the number of values in the msLimitLoginUserInfo attribute on the user's object in the Limitlogin Application Directory Partition (e.g. CN=User's SamAccountName,DC=LimitLogin,DC=domain name,DC=com). If the number of values on this attribute equals (or exceeds) the integer value specified on the msLimitLoginQuota, then the user is denied from logging in. You can delete one of the values in the msLimitLoginInfo attribute to allow the user to login again. This can be done from the UI by right clicking the User object in Active Directory Users & Computers, choosing "LimitLogin Tasks" and deleting one of the sessions displayed there (You can install the Active Directory MMC Integration tools by running the LimitLoginADSetup.msi installer). You can also use raw level editing tools such as ADSIEDIT.msc from the Support Tools to achieve the same result.
Q8: When I view the logins information in the MMC or in the report, some users show up with outdated names. Why is this happening?
A: When a domain user is configured to a certain logins quota, an object is created for that domain user in the LimitLogin Application Directory Partition (ADP). On creation, the object that is created for the domain user copies over the user's SamAccountName (login name) and the user's full name (the 'name' attribute) to the LimitLogin ADP. This is done to ease the tasks of searching for logins information and creating reports, by retrieving the user login name and full name directly from the LimitLogin object without having to perform a second LDAP Bind to the corresponding domain user for each and every user. While this architecture increases performance in the overall daily LimitLogin operations, it may happen that from time to time domain users can modify their first or last names in the Domain Partition, thus creating inconsistencies between the names at the LimitLogin ADP versus the up-to-date names in at the Domain Partition. Furthermore, when a user is deleted from the Domain, there is not built in mechanism that deletes it's corresponding LimitLogin object in the LimitLogin ADP, thus it may lead to 'stale' objects in the LimitLogin ADP.
To easily overcome these possible inconsistencies, use the \program files\limitlogin\llogincmd.exe /UPDATE command.
For more information see the "Diagnostics and Maintenance" page in this help file.
Here are some Q&A about LimitLogon (from www.bink.nu):
LimitLogon Frequently Asked Questions
Q1: Will LimitLogin work with Windows 95/98 client machines?
A: No. LimitLogin supports the following operating systems:
* Windows 2000 Professional Service Pack 4 and above
* Windows 2000 Server Service Pack 4 and above (Including Terminal Server sessions)
* Windows XP Professional Service Pack 1 and above
* Windows Server 2003 (Including Terminal Server sessions)
Q2: Do I need SQL Server or any other type of database for LimitLogin to work?
A: No. LimitLogin uses your Active Directory database. It creates an Application Directory Partition on a Windows 2003 Domain Controller in the domain(s) you wish to use the application.
Q3: What level of Security does LimitLogin offer to effectively limit user logins in an Active Directory domain?
A: 'LimitLogin' offers better security model than previous tools such as 'CConnect', yet the current model in version 1.0 grants users read/write permissions on their own logins data attribute, thus leaving the possibility for malicious users to modify their own logins data (there is no possibility for users to modify their own logins quota or any other parameter). In addition, users can not temper with any other domain user's logins data other than their selves, and they cannot change anything else in the Application Directory Partition. You can also add further security by configuring LimitLogin to use SSL or IPSEC to prevent man-in-the-middle type of attacks. For more information, see the "Advanced Configuration Topics" page in this help file.
Q4: Is LimitLogin Supported by Microsoft?
A: No. Similar to the status of the resource kit tools and/or the support tools, LimitLogin is not officially supported by Microsoft (See the End User License Agreement in the \program files\LimitLogin directory). However, the MS field engineer(s) that wrote LimitLogin will make a best effort to help customers and partners to effectively use this product.
Q5: Do I need to switch my Active Directory Forest into Windows 2003 Forest Mode for LimitLogin to work?
A: No. LimitLogin is not dependant on your Active Directory Forest or Domain modes. It merely needs one Windows 2003 Domain Controller in the domain(s) you wish to use the application. Note that the Domain Naming Master FSMO Role needs to be running on a Windows 2003 Domain Controller in order to be able to create an Application Directory Partition.
Q6: I don't necessarily need to limit user logins. Can I use LimitLogin just to capture login data for managing my Active Directory environment more effectively?
A: Yes, you can. You can configure all users in the domain to have a relatively high login quota and simply let the scripts do their work of up[censored] your logins data, without reaching the quota that was set. The UI tools allow you to set the login quota up to 10 logins per user. You can use the sample script code under \program files\Limitlogin\Bulk_LimitUserLogins.vbs to set the logins quota to any value you desire. You can also scope this script to an Organizational Unit level. The default script runs on all the user accounts in the domain.
Q7: Some users don't log off properly (e.g. Hibernate their machines) and when they log in again they are automatically logged off due to their quota limit. How can I correct this?
A: The number of logins that the user has made is determined by counting the number of values in the msLimitLoginUserInfo attribute on the user's object in the Limitlogin Application Directory Partition (e.g. CN=User's SamAccountName,DC=LimitLogin,DC=domain name,DC=com). If the number of values on this attribute equals (or exceeds) the integer value specified on the msLimitLoginQuota, then the user is denied from logging in. You can delete one of the values in the msLimitLoginInfo attribute to allow the user to login again. This can be done from the UI by right clicking the User object in Active Directory Users & Computers, choosing "LimitLogin Tasks" and deleting one of the sessions displayed there (You can install the Active Directory MMC Integration tools by running the LimitLoginADSetup.msi installer). You can also use raw level editing tools such as ADSIEDIT.msc from the Support Tools to achieve the same result.
Q8: When I view the logins information in the MMC or in the report, some users show up with outdated names. Why is this happening?
A: When a domain user is configured to a certain logins quota, an object is created for that domain user in the LimitLogin Application Directory Partition (ADP). On creation, the object that is created for the domain user copies over the user's SamAccountName (login name) and the user's full name (the 'name' attribute) to the LimitLogin ADP. This is done to ease the tasks of searching for logins information and creating reports, by retrieving the user login name and full name directly from the LimitLogin object without having to perform a second LDAP Bind to the corresponding domain user for each and every user. While this architecture increases performance in the overall daily LimitLogin operations, it may happen that from time to time domain users can modify their first or last names in the Domain Partition, thus creating inconsistencies between the names at the LimitLogin ADP versus the up-to-date names in at the Domain Partition. Furthermore, when a user is deleted from the Domain, there is not built in mechanism that deletes it's corresponding LimitLogin object in the LimitLogin ADP, thus it may lead to 'stale' objects in the LimitLogin ADP.
To easily overcome these possible inconsistencies, use the \program files\limitlogin\llogincmd.exe /UPDATE command.
For more information see the "Diagnostics and Maintenance" page in this help file.
