One of the key differences between a trust set up with Selective Auth and Forest Wide authentication is the group membership of users that come in over the trust. With Selective Auth enabled, users are not put in the “authenticated users” security group. In fact, if your domain trusts the netid domain with Selective Auth, your domain will not recognize users from NetID until you have explicitly given them permissions by adding them to a group or granting them a privilege on an object.
Adding Users as ForeignSecurityPrincipals
When a selective auth trust is established, no user objects from the trusted domain (netid) are added to the trusting domain. Users must be granted a permission on an object or added to a group to register with the domain. Once that is done the user is registered as an object of type “ForeignSecurityPrincipal” and added to the “ForeignSecurityPrincipals” OU.
To add a user to a group, first ensure that the group is of scope Domain Local. If your groups are Global, they cannot be directly changed to a Domain Local group. They can be changed to a Universal group via the GUI or “set-adgroup” in powershell. From there they can be changed again to a Domain Local group. If a Global group has another Global group as a member, that member group will need to be changed before the parent group can be changed. If you are not using existing groups, a new group can be scoped as Domain Local from creation.
Once the appropriate Domain Local groups are prepared, adding users via ADUC is slightly different than with local users. Open the groups properties, select the Members tab and click Add. Click the “Locations” button, and select netid.ucsb.edu. You can now add users by their netid’s. Once you click the the “OK” or “Check Names” button you will need to present any valid netid credentials to authenticate against the NetID domain and confirm your selection. These credentials should be presented in the form “NETID\yourucsbnetid”. No special permissions are needed for this account, as it is only retrieving data that is already available to any other netid user.
The ForeignSecurityPrincipal class has very few default attributes. Users that are brought into your domain will show up in the ForeignSecurityPrincipals OU only by the SID of the object or the “readable name” which gives the UCSBNetID of the user. The attributes of each FSP also do not reveal much information, and here the UCSBNetID isn’t even visible as it is a constructed attribute. However, when adding a user to a group it can be addressed by the UCSBNetID. More properties can also be added to these objects, though it will require scripting and custom AD schema extensions.
Assigning Rights
Since ForeignSecurityPrincipals aren’t added to the “authenticated users” group, users from the trust can not log in to any computers on the domain until they are added either directly or via group membership. Once we have identified a computer or OU of computers that a user should be able to log in to, we can grant that FSP/group the “allowed to authenticate” permission. For ease of administration, it is recommended to always add groups to permissions instead of individual users.
To grant log-in permissions for an OU, open the advanced permissions editor and add your user or group as the principal. In the “Applies to” dropdown, change the scope to “Descendent Computer Objects”. Now, select the “Allowed to authenticate” permission.To grant log-in permissions for an individual computer object, open the security properties for that computer, add the user through the basic interface, and check the “Allowed to authenticate” permissions box.
It should be noted that this puts the NetID user into the “Authenticated Users” group on the computers in question. You may still need to add the user or group to the local “Users” group on the computer depending on your AD’s policies and security settings, and will almost certainly need to add it to the “Remote Desktop Users” group if remote access is desired.
For a user to log in to that computer, they will need to specify their domain as NetID by logging in as either “netid\usersnetid” or “usersnetid@netid.ucsb.edu”
Example Setup
In the following example we will be discussing the way in which the domain rad.ucsb.edu assigns user permissions after trusting netid.ucsb.edu via selective auth.
First, let’s create the OU structure for our computers and users. Here you can see I’ve created a Computer Accounts and User Accounts OU, with various departmental OU’s as children. I’ve also added my first two user groups for the Earth Science department, EarthSci Admins and EarthSci Users.
We can now start populating those groups - for the users group we’ll add Joe Gaucho:
Now that Joe Gaucho is added to a group, we can see the ForeignSecurityPrincipal Object for that user:
We can now add login permissions to the appropriate OU for Earth Science to our new users group.
Overcoming ForeignSecurityPrincipal Limitations
Given that ForeignSecurityPrincipal objects have very few attributes, they can be challenging to work with. However, we can overcome some of these limitations via a combination of extending the AD schema and scripting.
Some schema attributes that may be handy are givenName, sn and ucsbNetID. We can implement these by creating a new auxiliary class and linking givenName and sn to our new class. To create the ucsbNetID attribute a “case insensitive string” with a minimum of 1 and maximum of 64 can also be created and linked to the new auxiliary class. By setting that class as an auxiliary class for the foreignSecurityPrincipal class we will now show those attributes for all FSP objects.
To then populate those attributes for each user, we’ll need a script to grab that data from the netid.ucsb.edu domain and set it on our foreignSecurityPrincipal objects. The “setUCSBNetIDAttributes.ps1” script that accomplishes this can be found on the MAUG github. That script can be set as a scheduled task to automatically run every day.
Powershell Notes
Because the objects coming from NetID are ForeignSecurityPrincipals instead of User objects, some normal admin tasks may not work as expected. For example, you cannot run “get-aduser” to find a user by their NetID. However, you can run the following to get a user object from netid: Get-ADUser “UsersNetID” -Server netid.ucsb.edu -Credential $credential -Properties $Properties
Other common commands for user and group management may also fail or be very cumbersome to use. It is highly recommended to use custom tooling if you anticipate needing to use powershell for group management with a selective auth setup. A module to handle these operations is available at https://github.com/ucsb/msadmins/tree/main/campus-ad/scripts
Add Comment