none
[PS][Security][New-PSDrive]Reading cached credentials RRS feed

  • Question

  • Hello fellow scripters,

    I'm currently stumped on one question ...

    What I'm trying to do
    After connecting to a PSDrive (Filesystem Provider) using "New-PSDrive" with different Credentials I can read the credentials used, utilizing "Get-PSDrive". Once I close powershell and restart it however, I can connect without using the credentials (which means they are cached somewhere) and the Credentials property on the PSDrive is empty.

    I want to read the Username used in those credentials reliably, no matter whether powershell was closed and opened again.

    Why
    For common usage, that is good, as people dislike entering a password over and over again, so I do want to reconnect without asking for credentials. However, I have a scenario where I want to know the Username used in those credentials to connect each time. During the first execution, that's simple (Get-PSDrive will return the info), however in later created processes I can't seem to be able to access this information.

    Ideas so farNow I could write that info down somewhere during the first execution and read it again later on, but I would prefer to avoid doing this as much as possible. It adds complexity and is not reliable in some of our scenarios. Added to that, it would also violate some of our compliance rules (Writing down security relevant information - including user names - is prohibited at some of our customers).

    Online search so far has only yielded ways to remove credentials (and manually, at that) ...

    Cheers and thanks in advance for any insights,
    Fred


    There's no place like 127.0.0.1

    Friday, February 28, 2014 11:01 AM

Answers

  • Why would you expect their to be credentials if you didn't use any to begin with?

    Once you have a conn3ection to a resource you no longer need to authenticate.  Once you session has a token for the resource the session does the authentication for you.  You cannot access this information. It is a Kerberos token stored in the kerberos ticket.  It is just a number.

    Think about it.


    ¯\_(ツ)_/¯

    • Marked as answer by FWN Monday, March 3, 2014 4:58 PM
    Monday, March 3, 2014 4:51 PM
  • Hi jrv,

    as it happens, I was in ignorance of just where it was stored, which is why I asked for where that information was stored. If it's inaccessible in the kerberos ticket ... well that's that and answers my question:

    It's impossible to do internally

    Which happens to be the information I was after (even if it's bad news), thanks (yes, I ought to do some reading up on Windows Security, I'll see whether I can fit in this weekend ....).

    Cheers,
    Fred


    There's no place like 127.0.0.1

    • Marked as answer by FWN Monday, March 3, 2014 4:58 PM
    Monday, March 3, 2014 4:58 PM

All replies

  • Start by typing "HELP New-PsDrive -Full". Read all of the instructions very carefully.

    If you are using PowerShell V2 or earlier then what you are trying to do cannot be done.


    ¯\_(ツ)_/¯

    Friday, February 28, 2014 3:14 PM
  • Hello Jrv,

    thanks for the reply, but I failed to find the information you were referring to. While calling the help function made for pleasant reading (I hope you'll forgive me for preferring the "-online" switch, easier to read and always up-to-date (I hope)), it did not contribute to my question. I have no trouble establishing a connection and am fully aware that using the Credentials switch is V3+ for UNC paths.

    What I am trying to do is read the used credentials in a different Powershell Process, where I am capable of reestablishing the connection without the credentials switch. That process has to be aware of the given credentials, since access limitations apply as they should, but the information is not provided in the psdrive information.

    Cheers,
    Fred


    There's no place like 127.0.0.1

    Friday, February 28, 2014 3:37 PM
  • If you read carefully then you know that drives are not visible across sessions but only in the system that created the drive.

    You can, however persist the drive with admin elevation but the drive will still only be visible to admin sessions.  Somewhere there is a registry setting that alters this behavior.


    ¯\_(ツ)_/¯

    Friday, February 28, 2014 3:47 PM
  • I just decided to look at the online help:

    The ONLINE help is not correct.  Please look at the updated local help for the complete description and full set of examples.

    You must learn to use 'Scope" and 'Persist" to have the drives visible as you want them.

    '


    ¯\_(ツ)_/¯

    Friday, February 28, 2014 3:53 PM
  • Hi Jrv,

    we appear to be having a slight communication problem, so I think I better Detail it step-by-step:

    Process:

    1. Start a powershell console with User A
    2. Connect a remote share (which is hosted on a server in a different, untrusted domain) with "New-PSDrive", giving it the credentials needed.
    3. Using "Get-PSDrive" I can read the credentials (Clear-Text Username, Secure String PW of course)
    4. Start an elevated Powershell console from within this console.
    5. Connect the same remote share (Wants the Credentials again)
    6. Using "Get-PSDrive" I can read the credentials (Clear-Text Username, Secure String PW of course)

    Now close both Powershell Consoles and do other things for a few hours (Whatever the job demands).
    7 Hours later ...

    1. Start a powershell console with User A
    2. Connect the same remote share again (it does not prompt me for credentials)
    3. Using "Get-PSDrive" I cannot read the credentials.
    4. Start an elevated Powershell console from within this console
    5. Connect the same remote share again (it does not prompt me for credentials)
    6. Using "Get-PSDrive" I cannot read the credentials.

     

    My Issue:
    My problem is with step 3 and 6 of the second iteration. I want to know - programatically - which credentials are used to establish the connection, even if it is a second or third established connection where the user was not prompted for credentials.
    For this to be possible, the system has to cache and reuse the credential and have it associated with the remote resource, which may, or may not be accessible. Knowing whether it is possible (and if yes: how) is what I'm after.

    Cheers,
    Fred


    There's no place like 127.0.0.1


    • Edited by FWN Monday, March 3, 2014 9:25 AM
    Monday, March 3, 2014 9:23 AM
  • It works fin for me.

    Just look at the properties of the drive object. The credentials are their in plain text with a secured password object.

    (get-psdrive P).Credential.Username


    ¯\_(ツ)_/¯

    Monday, March 3, 2014 1:23 PM
  • hi Jrv,

    I am looking there. After the first set of six steps they are there.
    After the second set of six steps (where I did not pass credentials, since it wasn't necessary then), the field is blank for me (the credentials object is there, but both its fields are null).

    Cheers,
    Fred


    There's no place like 127.0.0.1

    Monday, March 3, 2014 4:21 PM
  • Why would you expect their to be credentials if you didn't use any to begin with?

    Once you have a conn3ection to a resource you no longer need to authenticate.  Once you session has a token for the resource the session does the authentication for you.  You cannot access this information. It is a Kerberos token stored in the kerberos ticket.  It is just a number.

    Think about it.


    ¯\_(ツ)_/¯

    • Marked as answer by FWN Monday, March 3, 2014 4:58 PM
    Monday, March 3, 2014 4:51 PM
  • Hi jrv,

    as it happens, I was in ignorance of just where it was stored, which is why I asked for where that information was stored. If it's inaccessible in the kerberos ticket ... well that's that and answers my question:

    It's impossible to do internally

    Which happens to be the information I was after (even if it's bad news), thanks (yes, I ought to do some reading up on Windows Security, I'll see whether I can fit in this weekend ....).

    Cheers,
    Fred


    There's no place like 127.0.0.1

    • Marked as answer by FWN Monday, March 3, 2014 4:58 PM
    Monday, March 3, 2014 4:58 PM
  • Yes it is not available if you didn't explicitly set it.  It is called a proxy.  If you know what you are looking for their are utilities that can get all proxy accounts in use.  You cannot get the password but you can get the ID.  The problem is that there is no way that I can see to relate a "proxied" drive to a resource except by server name.  If you have the path of the drive then match that to the credentials cache to see if it matches the resource server.  If it is a domain proxy then you will have to find the domain for the server and look up the ID.

    You marked your own statement as an answer.  It was not the answer. The answeris that you cannot get it from a drive that has not been set with explicit credentials.


    ¯\_(ツ)_/¯

    Monday, March 3, 2014 5:07 PM
  • I marked it as an answer because it clearly states the final answer to the question. If someone later researches the same question s/he may be a bit confused without reading it all otherwise, as your answer is in the context of the previous posts. Just wanted to make it a bit easier on the next person (It's not like I could -or would for that matter - award myself with points or anything after all).

    There's no place like 127.0.0.1

    Monday, March 3, 2014 5:29 PM
  • I marked it as an answer because it clearly states the final answer to the question. If someone later researches the same question s/he may be a bit confused without reading it all otherwise, as your answer is in the context of the previous posts. Just wanted to make it a bit easier on the next person (It's not like I could -or would for that matter - award myself with points or anything after all).

    There's no place like 127.0.0.1


    Oh.  Ok.

    ¯\_(ツ)_/¯

    Monday, March 3, 2014 6:22 PM