What happens when you try? As a work-around add the accounts to a group and then add the group.
--please don't forget to upvote
and Accept as answer
if the reply is helpful--
This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
Hello!
I am trying to use the Log On To section to allow a service user account to log into certain machines. Per this link the limit is 64 values, however I only have 49 entries and cannot add more. When I try to remove one and add a new one, I still get the error "that the property is limited to 64 values. "
I am not sure why I cannot add more, even when I delete some.
What happens when you try? As a work-around add the accounts to a group and then add the group.
--please don't forget to upvote
and Accept as answer
if the reply is helpful--
Might try the PowerShell method mentioned here.
http://woshub.com/restrict-workstation-logon-ad-users/
--please don't forget to upvote
and Accept as answer
if the reply is helpful--
The limit of the attribute is based on the total length of the workstation names, rather than the total number of entries. The max length of the attribute is 1024, the 64 is based on 1024/16 = 64, if you have longer names then it will hold fewer names.
As stated in the article you can increase the max length from 1024 to 8192, which could support up to 512 names.
This LDF file can be used to change the size of the attribute:
dn: CN=User-Workstations,CN=Schema,CN=Configuration,DC=<yourdomain DN>
changetype: modify
replace: RangeUpper
RangeUpper: 8196
-
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
Update your domain name and save this as a text file
Then use this command to update the schema:
ldifde -i -f <filename>
Gary.
I wouldn't even use this attribute. It is inherited from the OS2 days. Where the current limit was fine and when DNS wasn't even a thing (you add NetBIOS names to this).
To restrict where user can connect from and to, use the User Right Assignment section of group policies or the even newer one Authentication Policies and Silos.
Although the easiest to deploy and manage will be the User Right Assignment. It is more granular, you can explicitly allow or deny a type of logon. For example, for an account used by an application (like a "service account") you could limit it to a "Allow logon as a service" or if that's for a schedule task or an IIS App Pool "Allow log on as a batch".
On that note, if the account is in fact used by an application, you should consider using Group Managed Service Account instead. It will solve the issue of "Log On To" because you can allow the account on the machine of your chose without that attribute, you don't have to manage the password, and nobody can cheat and use this account to so something because their own account doesn't have the permissions (since 1. they don't know what the password is, it is managed and changed automatically by the system and 2. you can't open interactive session with that type of account).