Last week in my Blog I mentioned the Active Directory AMT Objects and things to watch for when working with them. Today I want to share a possible temporary solution.


So to recap, current objects that are created by the SCS are not being treated as true “computer” objects. They end up being returned by queries as user objects, and that leads to some confusion.


One way that I have dealt with these objects is to restrict “list” access to them. This way they do not show up in AD searches and users (like me) are less likely to select them on accident.


So let’s take a look at the object again. I provisioned this client using AD integration and TLS using SCS

Here is the AD Object that was created:


And remember when we search for this particular computer name, it is returned as a user object (notice how I do not have Computer objects selected for object types in the search below)


One way I have found to prevent this from returning in queries is to specifically deny “list contents” for the AMTOU container and all the descendant objects.

In this example, I am logged in with a user account “amt\Josh”, which happens to have full control of the AMT device.


Now we modify the permissions on the OU, and Deny List Contents for This object and all descendant objects for the accounts and groups we do not want to find the AMT objects:


**Keep in mind that the SCS service account still needs Full Control in this OU for provisioning/unprovisioning**

**I would treat this as a temporary workaround and be very careful about making any changes to the OU in your production envronment!**


This will basically “hide” the AMT AD objects from that certain group or user (amt\josh in this case).

Now when we query for the machine name:


We get the above error message, which forces us to add the “Computer” object types to the query:



And finally we only get our true computer AD object returned from the query.


This is just a simple test method we have used in the lab to prevent the AMT objects from showing up in AD searches. You will want to consult with your network/active directory owner for best practices of hiding AD objects in your production environment.


To show that the account is still able to authenticate and connect to AMT, here is a screenshot showing a successful command from the AMT vPro PowerShell Module:



If you have any other creative ways of hiding these objects, I would love to hear about them!