I have been banging my head against a wall on trying to automate a local admin rights assignment process and am probably too close to the issue and hope that some here might might have some insight that can help.
Right now the current manual process is:
(I know that this isn't ideal, but unfortunately it is what we have)
* User puts in request
* Users manager approves request
* IT Admin approves
* IT Admin adds PC to filter group (prevents AD from stripping out non-approved local admins)
* Wait for replication to occur (no clue how long this takes, am also planning on working on a script that will check all domain controllers)
* add user to local admin
* refresh local policy (if user is removed add them again)
* if user is removed a 2nd time, request the user reboots the PC
* add them again and refresh policy (this should be the end)
The biggest issue I currently have right now, especially as we have a large mobile workforce, is one of timing. By the time we get to the part of adding the user to the local admin group the PC may be offline and it could take a while before we see it again. And it is a manual process to check if PC is online or not.
OK, with all that said, I have tried several things and my main issue is how to tie the approved username to the PC. Is there a way to pass the primary user (UDA) of a PC to the script that adds to the local admin group?
Options I have looked at and / or tested so far are:
Collection - Based on the filter group (all the below will use the same device collection)
Unless otherwise noted, all applications need to run under the system context so that the username can be added to the local admin group.
Application - A script that is deployed against the above collection that adds the current user to the local admin group (use LastLoggedonSamUser from registry)
OR
Application - A script that is deployed against the above collection that reads the computer AD description and adds the user(s) listed there to the local admin group (this has been tested). Additionally I can read from a tag file on the PC or on the network.
OR
Compliance settings - 2 scripts, 1 to check for compliance, that current user is in admin group and 1 to add current user to admin group. I have tested it and was successful checking for compliance but haven't got the 2nd script working yet, but this still has the issue that I need to tie the approved username to the pc and only add the approved user.
Not tested, but did something similar at a previous job but this was only adding users to remote desktop
2 scripts: (script 2 is a dependency on script one)
1) deploy to user, it checks if current user is in admin group
2) adds current user to local admin group
Additionally, I have the issue of requiring a reboot to make sure that the policy is no longer applied and while many times all it takes is switching from wired to wireless, requesting a reboot is normally the easiest thing to have a user do. So, with that in mind (and again while I was typing this up) I thought of adding a 2nd script as a dependency to all the above and that all this script did was prompt the user (hopefully the correct user) to reboot and returned to SCCM a required Hard reboot, which if I am not mistaken, would prevent the first script from running until a reboot has been performed.
Pretty much all of the options have the issue of only adding the approved user to the correct PC.
Right now the current manual process is:
(I know that this isn't ideal, but unfortunately it is what we have)
* User puts in request
* Users manager approves request
* IT Admin approves
* IT Admin adds PC to filter group (prevents AD from stripping out non-approved local admins)
* Wait for replication to occur (no clue how long this takes, am also planning on working on a script that will check all domain controllers)
* add user to local admin
* refresh local policy (if user is removed add them again)
* if user is removed a 2nd time, request the user reboots the PC
* add them again and refresh policy (this should be the end)
The biggest issue I currently have right now, especially as we have a large mobile workforce, is one of timing. By the time we get to the part of adding the user to the local admin group the PC may be offline and it could take a while before we see it again. And it is a manual process to check if PC is online or not.
OK, with all that said, I have tried several things and my main issue is how to tie the approved username to the PC. Is there a way to pass the primary user (UDA) of a PC to the script that adds to the local admin group?
Options I have looked at and / or tested so far are:
Collection - Based on the filter group (all the below will use the same device collection)
Unless otherwise noted, all applications need to run under the system context so that the username can be added to the local admin group.
Application - A script that is deployed against the above collection that adds the current user to the local admin group (use LastLoggedonSamUser from registry)
OR
Application - A script that is deployed against the above collection that reads the computer AD description and adds the user(s) listed there to the local admin group (this has been tested). Additionally I can read from a tag file on the PC or on the network.
OR
Compliance settings - 2 scripts, 1 to check for compliance, that current user is in admin group and 1 to add current user to admin group. I have tested it and was successful checking for compliance but haven't got the 2nd script working yet, but this still has the issue that I need to tie the approved username to the pc and only add the approved user.
Not tested, but did something similar at a previous job but this was only adding users to remote desktop
2 scripts: (script 2 is a dependency on script one)
1) deploy to user, it checks if current user is in admin group
2) adds current user to local admin group
Additionally, I have the issue of requiring a reboot to make sure that the policy is no longer applied and while many times all it takes is switching from wired to wireless, requesting a reboot is normally the easiest thing to have a user do. So, with that in mind (and again while I was typing this up) I thought of adding a 2nd script as a dependency to all the above and that all this script did was prompt the user (hopefully the correct user) to reboot and returned to SCCM a required Hard reboot, which if I am not mistaken, would prevent the first script from running until a reboot has been performed.
Pretty much all of the options have the issue of only adding the approved user to the correct PC.