Weird Credentials being Passed

PowerShell Help
1

Can anyone explain to me why the credentials that are used to create the PSDrive, are used to assign to the permissions after creating the folders that reference the PSDrive? I know for certain it’s doing this after much testing, but I can’t for the life of me figure out why, since the lower half assigning full control to the user… doesn’t reference the PSDrive at all. Thoughts?

New-PSDrive -Name FileServer -PSProvider FileSystem -Root “\Server\e$\Users$Department” -Credential $Cred_ModifyFolders
New-Item -ItemType Directory FileServer:$Username -Force
New-Item -ItemType Directory FileServer:$Username\Desktop -Force
New-Item -ItemType Directory FileServer:$Username\Documents -Force
New-Item -ItemType Directory FileServer:$Username\Favorites -Force

#Add NTFS Permissions to the home folder directory
$user = “domain$Username”
$dfsfolder = “\Server\E$\users$Department$Username”
$acl = get-acl -path $dfsfolder
$new = $user, “FullControl”, “ContainerInherit,ObjectInherit”, “None”, “Allow”
$accessRule = new-object System.Security.AccessControl.FileSystemAccessRule $new
$acl.AddAccessRule($accessRule)
$acl | Set-Acl $dfsfolder

2

That’s kind of a normal Windows thang. When you create a new folder, it’s “yours” by default. As far as Windows knows, the credential of the PSDrive is “you,” since that’s the credential being used to authorize the folder creation. You can add whatever permissions you like, of course, as you’re doing, but that doesn’t “remove” any existing permissions. You’d have to explicitly remove them.

3

I forgot to add that the Script is being run as a user that doesn’t have any rights on the server… and is essentially just a “Domain User”. Which is why the credential is being passed to create the Drive in the first place. So it isn’t like the powershell instance user is creating the drive, and then manipulating the rights. I hope I articulated that correctly.

4

You did, but a PSDrive is just a drive mapping. It’s no different than attaching a network drive in Explorer. That’s the credential being used to access the remote UNC, and so as far as the server is concerned, it’s who you are. Windows’ default behavior (with a couple of exceptions) is that whatever user creates a folder has permission to the folder (if you think about it, there aren’t very many instances where you want the creating user to NOT have access, so this behavior makes sense).

The user running the script doesn’t matter; and the script isn’t “creating a drive.” It’s just mapping a network drive, just as if you’d used NET USE. For the remote server, the PSDrive credential is what matters, as that’s the credential authorizing the connection, and authorizing the creation of the new folder.

5

Thanks for the replies, and yes you’re correct in all you’ve said. So hold on… is what your saying that the PSCredential is authorizing the account running the script to create the folders on the server? So when it comes time to assign rights, the creator (the one running the script who was authorized) is able to assign those right? IF that’s the case… then all of my testing makes sense, so I hope the answer is yes :stuck_out_tongue:

6
So hold on... is what your saying that the PSCredential is authorizing the account running the script to create the folders on the server?

Yeah, just like if you mapped a drive in Windows Explorer. The PSCredential is all the remote file server sees. If you were to check the security log on that server, you’d see the PSCredential account being used to connect and perform actions. Zero difference between this and mapping a drive in Explorer that uses alternate credentials. This is just how Windows has always worked.

But it’s not “the PSCredential is authorizing the account running the script.” The PSCredential isn’t “authorizing” anything. The PSCredential is what’s used to connect to the file server, and it’s actually a LOGON to that file server. Again, you can see it in the security log on the file server, if you’re auditing those events. The “account running the script” has nothing to do with anything, as far as the file server is concerned. The file server has no clue who is “running the script,” because all the file server sees is the credential used to map the drive.

So when it comes time to assign rights, the creator (the one running the script who was authorized) is able to assign those right?

I think you’re overthinking the “authorizing the account” stuff. The PSCredential used to map the PSDrive is the creator of any folders created in that drive. Ergo, the PSCredential gets permissions to those folders by default.

I’m worried that you’re thinking it’s like this:

Bob runs a script under his domain user account, UserBob.
The script maps a PSDrive using the account AdminBob.
The script changes to that PSDrive.
The script creates a folder.
The file server somehow gets permission from AdminBob to let UserBob create the folder.

That isn’t it.

Bob runs a script under his domain user account, UserBob.
The script maps a PSDrive using the account AdminBob.
AdminBob is now “logged in” to the file server (non-interactive logon over SMB)
The script changes to that PSDrive.
The script creates a folder.
Because AdminBob has permission to create the folder, the folder is created.
AdminBob has permissions to the new folder.

The file server has no idea who ran the script (UserBob), and the file server doesn’t care. There is only AdminBob, as far as the file server is concerned.

Again, this is exactly how Windows Explorer has always worked. If you duplicated these tasks in the GUI, you’d get the exact same result, with one exception: Explorer does a bit of a hedge that’s different. Normally, if a member of the local Administrators group creates a folder, then the local Administrators group is given permission to the new folder, rather than the specific admin who created the folder.

7

Ok, you are correct in how I was thinking about the authorization, but I have all of that straight in my head now, thank you.

But how is the second half of the script running successfully? The part that is assigning rights. It isn’t referencing the PSDrive for it’s folder locations… so it wouldn’t be those credentials acting on the folders, it’s just using the straight UNC path. So wouldn’t the account being used to run the script, be the one which is attempting to change the permissions on the folder?

8

Yup. So if I was curious, I’d investigate whether that user had permissions or not, or whether some other account was involved. I’d have to look at ACLs and security logs (assuming auditing was on) to do that. Easiest is to make sure auditing is on, perform an action, find the log entry for that action, and see who did it.

9

Yeah, Maybe I’ll have to get auditing working, I was hoping for a quick explanation as to why it would be happening. Running the first part to create the folders, commenting it out, including the creation of the PSDrive, and then running again doesn’t work, access denied. Running it a second time with only the folder creation commented out, so still mapping the PSDrive… it works, permissions assigned… so it seems like it’s using those creds… but I’ve no idea how/why.

Anyways, thanks for the tips and info, appreciate it. I’m new around here, but hopefully I’ll be able to contribute something meaningful :slight_smile: