PowerShell登录脚本以管理员身份

Question

I have a PowerShell script that I need to run at user logon. The script uses the AD module to see if a users is part of a group and get other info, plus also I get local variables like:

$env:DOMAINNAME
$env:USERNAME
$env:APPDATA
$env:TEMP

And is why I need it to run at logon but I think is a permission issue.

Any idea how could I do this? I tried adding the script under User Configuration → Policies → Windows Settings → Scripts → Logon , and it did not work, also tried under Computer Configuration .

Added -ExecutionPolicy Bypass as parameter and still nothing.

I also tried to add is as a scheduled task and run it as other user but still no luck.

Answer 1

Since you shared your code in one of the other comments, I can make some assumptions about what you're trying to achieve and help with that. So let's break it down.

ActiveDirectory Module

The first thing we need to do is remove the dependency on the ActiveDirectory module. As explained by some of the comments here, the ActiveDirectory module is a built-in component of the RSAT suite. When this script is running on your client computers, this won't be available and we don't want to make it available as it creates a large dependency overhead and exposes admin utilities to your users.

The cmdlets you're using are simply Get-ADUser , Get-ADGroup and Get-ADPrincipalGroupMembership . These are search cmdlets using the Lightweight Directory Access Protocol (LDAP), and so we can replace them with our own search functions using .NET classes.

Get-ADUser

We can replace the Get-ADUser search cmdlet with our own function defined at runtime like so:

function Get-ADUser 
{
    Param ( [string]$Identity = $null )
    IF ($Identity)
    {

        $UserSearcher = New-Object DirectoryServices.DirectorySearcher
        $UserSearcher.SearchRoot = "LDAP://$("DC=$(($ENV:USERDNSDOMAIN).Replace(".",",DC="))")"
        $UserSearcher.Filter = "(&(objectCategory=person)(SAMAccountName=$Identity))"

        $UserSearcher.FindAll() | foreach {New-Object PSObject -Property:$_.Properties}
    }
}

Get-ADGroup

We also need to replace the Get-ADGroup cmdlet so that we can grab the AD Groups you've specified in your $OfficeLocations list.

function Get-ADGroup 
{
    Param ( [string]$Identity = $null )
    IF ($Identity)
    {

        $GroupSearcher = New-Object DirectoryServices.DirectorySearcher
        $GroupSearcher.SearchRoot = "LDAP://$("DC=$(($ENV:USERDNSDOMAIN).Replace(".",",DC="))")"
        $GroupSearcher.Filter = "(&(objectCategory=group)(SAMAccountName=$Identity))"

        $GroupSearcher.FindAll() | foreach {New-Object PSObject -Property:$_.Properties}
    }
}

Get-ADPrincipalGroupMembership

This cmdlet doesn't need to be replaced - not because it will work on it's own, but instead because you don't require it to achieve your desired end result. You have used it to retrieve group memberships from an AD User, however the AD User has a list of their memberships attached to their AD User object. So in essence, we can get a list of an AD User's memberships directly from the AD User object, and we will do that like this:

$userObject = Get-ADUser -Identity $env:USERNAME
$objGroup = $userObject.memberOf

What you will notice at this point is that the result set is not the group names, but their distinguished names. This is also just a string array of those distinguished names, and you will have to make some modifications to the rest of your code's comparison operators that filters this list of groups.

Deploying your code

The second thing we need to look at is how you're deploying this code. There are numerous ways that you can achieve this, but let's assume that you're able to get the script deployed to the end user and assume that it runs.

Context

The method you use to deploy this code needs to align with the code itself. If your script makes assumptions about the context it's running in (such as using $env:USERNAME to gather the user's SAMAccountName for AD), then you need to ensure that the deployment method makes this assumption as well. The script as it is right now is making that assumption - the assumption that it's the user's own context running this code.

To support this assumption, we need to make sure that the deployment method is going to run the script as the user .

Dependencies

Now we know that the code is running as the user in their own context on the user's machine, and we know that the code accesses external resources such as Active Directory, we need to make sure that the user has the rights to these dependencies the code has, to ensure that the code will work.

Make sure you go through your code and list out all the tasks that the code performs. By that, I mean note that the code will read the user's own AD object, and it will read a network location to access signature files, and it will read & write to the user's own registry, as well as write to the user's appdata path.

In Conclusion

With those dependencies verified, and with the deployment method lining up with the code, you should have yourself a working product. Your code suggests there is a lot you have to learn about Powershell but if you keep at it and hone your understanding of fundamentals, you'll be ok. Keep learning, keep breaking stuff, and always remember to have fun along the way.