none
Drive Mapping PowerShell Script Locking Domain Account RRS feed

  • Question

  • I created a number of drive mapping scripts since my job requires accessing a large number of files on different servers, in a separate domain, based on the task at hand.  After fat-fingering my password into Get-Credential a few times and locking my account in the other domain, I added code to test my credentials prior to executing the series of New-PSDrive commands.  Since then, I have noticed my account getting locked after running the scripts, despite using the correct username and password.  Here is the sanitized code I am using:

    Write-Host "Press any key to enter <Second Domain> credentials and map <Second Domain> domain drives..."
    $x = $host.UI.RawUI.ReadKey("NoEcho,IncludeKeyDown")

    ## Prompt for credentials
    $Credential = $host.ui.PromptForCredential("Need <Second Domain> credentials", "Please enter MCG\username and password.", "", "")
    $UserName = $Credential.UserName
    $Password = $Credential.GetNetworkCredential().password
    $CurrentDomain = "LDAP://DC=<Second Domain>,DC=com"
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,$UserName,$Password)

    if ($domain.name -eq $null)
    {
    write-output "Authentication failed - please verify your username and password."
    exit #terminate the script.
    }
    else
    {
    write-output "Successfully authenticated with domain " $domain.name
    }

    ## Map Drives in <Second Domain> domain using credentials supplied via pop-up
    New-PSDrive -Name H -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\C$ -Credential $Credential -Persist
    New-PSDrive -Name I -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\C$ -Credential $Credential -Persist
    New-PSDrive -Name J -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\E$ -Credential $Credential -Persist
    New-PSDrive -Name K -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\F$ -Credential $Credential -Persist

    When I watch the logs on the domain controllers, I see a failed logon using credentials for the domain I am in followed by a successful logon using the supplied credentials for each New-PSDrive command executed.

    Can somebody help me understand what is going on here and why the account I supplied credentials for is getting locked out?

    Tuesday, July 28, 2015 9:50 PM

Answers

All replies

  • Why are you trying to log into the domain with LDAP?  That is not needed to map drives.


    \_(ツ)_/

    Tuesday, July 28, 2015 10:14 PM
  • This is the only thing you can do:

    $credential=Get-Credential #prompt remote domain ADMIN for credential
    
    New-PSDrive -Name H -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\C$ -Credential $Credential -Persist
    New-PSDrive -Name I -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\C$ -Credential $Credential -Persist
    New-PSDrive -Name J -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\E$ -Credential $Credential -Persist
    New-PSDrive -Name J -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\E$ -Credential $Credential -Persist
    New-PSDrive -Name K -PSProvider FileSystem -Root \\<Server Name>.<Second Domain>.com\F$ -Credential $Credential -Persist
    
    
    
    

    You must be an admin on the remote machine and there must be a functional trust.

    Be sure no failed maps have been persisted or they wi continue to lock you out.

    If the clocks do not match you may also get locked out.  Be sure clocks between local and remote DCs match.


    \_(ツ)_/

    Tuesday, July 28, 2015 10:20 PM
  • The LDAP portion, and associated code, listed below separately, was inserted to test the credentials.  I added it to avoid locking my account due to entering the incorrect password because some of these script map 10-15 drives.  That is a quick way to lock the account.  This code has saved my bacon a few times, but now I am seeing this odd lockout behavior, despite entering the correct credentials.

    $UserName = $Credential.UserName
    $Password = $Credential.GetNetworkCredential().password
    $CurrentDomain = "LDAP://DC=<Second Domain>,DC=com"
    $domain = New-Object System.DirectoryServices.DirectoryEntry($CurrentDomain,$UserName,$Password)

    if ($domain.name -eq $null)
    {
    write-output "Authentication failed - please verify your username and password."
    exit #terminate the script.
    }
    else
    {
    write-output "Successfully authenticated with domain " $domain.name
    }

    Wednesday, July 29, 2015 3:04 PM
  • You don't need to prompt for credentials if you open your PowerShell window with the alternate credentials in the first place.

    -- Bill Stewart [Bill_Stewart]


    Wednesday, July 29, 2015 3:14 PM
    Moderator
  • I see the same behavior. Basically, we run a powershell script every 15 minutes from an server which is on AD. This scripts connects to a share drive using New-PSDrive; the remote server is not on AD so proper credentials are provided.

    Every time the script runs, there is an "Audit Failure" (4625) on the event logs with the server AD info and whatever AD credentials the powershell was running although the script explicitly passes the remote server credentials... the connection to the shared drive is done successfully but the "Audit Failure" error is annoying since our LEM system is complaining of the failed attempts.

    Anyone have any idea why New-PSDrive is trying first the current credentials before trying the explicit one?

    Tuesday, April 3, 2018 6:03 PM
  • I don't know, but I suspect that it's by design.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, April 3, 2018 6:08 PM
    Moderator
  • Were you ever able to find a work around or more information about this behavior?

    We also use New-PSDrive with a scheduled PowerShell script to securely map remove server drives, but the "Audit Failure" events are driving me crazy. In our environment New-PSDrive tries 3-4 times with the current credentials before trying the explicit set.

    Monday, December 10, 2018 6:43 PM