• Welf Alberts liked the comment of Welf Alberts (Rank 3) on Sleep computer (remotely) from the command line. (So far, Welf Alberts (Rank 3) has 2 likes for this comment) 2 weeks, 6 days ago

  • Some thoughts:

    rundll32 can be invoked from remote, using the usual suspects:
    rundll32.exe powrprof.dll,SetSuspendState 0,1,0
    (will hibernate if hibernate is enabled, else, it will let the machine sleep)

    Native powershell code:
    Add-Type -Assembly System.Windows.Forms
    $state = [System.Windows.Forms.PowerState]::Suspend
    [System.Windows.Forms.Application]::SetSuspendState($state, $false, $false) | Out-Null

  • Hi.

    It should be noted that requiring enhanced PINs poses a big problem: Microsoft has not designed it in a way that respects the keyboard layout. So on a qwertz keyboard, you set an enhanced PIN of zaza123 but when booting your machine, you will need to enter yaya123 (which is the corresponding key combination if you had a qwerty keyboard). So I even wrote a script that translates qwertz enhanced PIN entries to the US keyboard layout which Bitlocker hopes to find so that you can enter any enhanced PIN without headaches. See this:
    $enhacedPIN = $enhacedPIN -creplace “@”,””
    $enhacedPIN = $enhacedPIN -creplace ‘”‘,’@’
    $enhacedPIN = $enhacedPIN -creplace “~”,””
    $enhacedPIN = $enhacedPIN -creplace “€”,””
    $enhacedPIN = $enhacedPIN -creplace “{“,””
    $enhacedPIN = $enhacedPIN -creplace “[“,””
    $enhacedPIN = $enhacedPIN -creplace “]”,””
    $enhacedPIN = $enhacedPIN -creplace “+”,”]”
    $enhacedPIN = $enhacedPIN -creplace “}”,””
    $enhacedPIN = $enhacedPIN -creplace “”,””
    $enhacedPIN = $enhacedPIN -creplace “z”,”ô”
    $enhacedPIN = $enhacedPIN -creplace “y”,”z”
    $enhacedPIN = $enhacedPIN -creplace “ô”,”y”
    $enhacedPIN = $enhacedPIN -creplace “Z”,”ô”
    $enhacedPIN = $enhacedPIN -creplace “Y”,”Z”
    $enhacedPIN = $enhacedPIN -creplace “ô”,”Y”
    $enhacedPIN = $enhacedPIN -creplace “ü”,”[”
    $enhacedPIN = $enhacedPIN -creplace “Ü”,”{”
    $enhacedPIN = $enhacedPIN -creplace “:”,”>”
    $enhacedPIN = $enhacedPIN -creplace “Ö”,”:”
    $enhacedPIN = $enhacedPIN -creplace “;”,”<"
    $enhacedPIN = $enhacedPIN -creplace "ö",";"
    $enhacedPIN = $enhacedPIN -creplace "ô",";"
    $enhacedPIN = $enhacedPIN -creplace "|",""
    $enhacedPIN = $enhacedPIN -creplace "'","|"
    $enhacedPIN = $enhacedPIN -creplace "Ä",'"'
    $enhacedPIN = $enhacedPIN -creplace "'",""
    $enhacedPIN = $enhacedPIN -creplace "ä","'"
    $enhacedPIN = $enhacedPIN -creplace "#",""
    $enhacedPIN = $enhacedPIN -creplace "-","ô"
    $enhacedPIN = $enhacedPIN -creplace "&","^"
    $enhacedPIN = $enhacedPIN -creplace "/","&"
    $enhacedPIN = $enhacedPIN -creplace "ô","/"
    $enhacedPIN = $enhacedPIN -creplace "§","#"
    $enhacedPIN = $enhacedPIN -creplace "_","ô"
    $enhacedPIN = $enhacedPIN -creplace "?","_"
    $enhacedPIN = $enhacedPIN -creplace "ô","?"
    $enhacedPIN = $enhacedPIN -creplace "*","}"
    $enhacedPIN = $enhacedPIN -creplace "(","*"
    $enhacedPIN = $enhacedPIN -creplace ")","("
    $enhacedPIN = $enhacedPIN -creplace "=",")"
    $enhacedPIN = $enhacedPIN -creplace "ß","-"

  • Hi fellows.

    As the title suggests, this is about RemoteApps from a RD Session Host (Server 2019, 1809).

    In the past, I published Apps through the server manager GUI and everything worked. I often limited Apps to certain user groups, since we deploy them to the start menu and some should not appear anywhere using the suitable GPO (User Configuration / Policies / Administrative Template / Windows Component / Remote Desktop Service / RemoteApp and Desktop Connections ->specify default connection URL).

    Today, I publish a new app as usual but it gets deployed to users that shouldn’t see it. I verified with the command
    (Get-RDRemoteApp -alias RemoteAppAliasName).usergroups
    that the user group is indeed set on the app, but the clients don’t respect that.

    I dug deeper and found the security descriptors to manifest at the server’s registry at

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerCentralPublishedResourcesPublishedFarms”Collectionname”Applications”RemoteAppAliasname”

    and

    HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionTerminal ServerTSAppAllowListApplications”RemoteAppAliasname”

    and they are correct! So why wouldn’t the clients respect them anymore?

    I am aware that very few people will have ever stumbled across this. So please only answer if you are in the know and are sure that you know how visibility privileges on RemoteApps work.

  • Another thing: Win11 22H2 cannot use remote credential guard unless the RDP target is 22H2 as well! Please try it out. You may logon remotely, but any share access will trigger a re-authentication prompt.100% reproducible anywhere.

  • No one?

    In the mean time, I need to correct myself: it happens anywhere, no matter what DC OS.

    What I was observing in my lab was different, because there, I had used Win11 22H1. 22H2 seems to introduce this bug.

  • ***copied my own question from https://www.experts-exchange.com/dashboard/#/questions/my/29260167 ***

    Hi AD experts!

    To participate, you should be familiar with “remote credential guard”.

    Situation:

    DCs: Server 2016 1607

    Clients: Win10 22H2, however we are starting to add Win11 22H2 to this mix.

    RDPing from Win10 to Win10, there are no problems, neither from Win11 to Win11.

    However, from Win11 to Win10 or the other way round, we see the following problem:

    As soon as we activate remote credential guard, we have to re-authenticate whenever we try to access file shares from within a remote session.

    We see the same problem when we use RDP from Win11 to Server 2019.

    If we use ipaddress instead of the name, we don’t have to re-authenticate.

    I can reproduce this problem anywhere, even on clean installations with no software or GPOs on them.

    Now for the interesting part: in my test domain, which already has server vNext (preview) as DC, everything works, which suggests that our DCs are the root problem.

    Since I cannot upgrade these DCs just for a test, I am hoping for confirmation from others that also run server 2016 1607 as DC OS.

    Disclaimer: Folks, I am not looking for explanations or theories. I am just trying to find others with this OS on their DCs that have Win11 and Win10 with remote credential guard active in order to tell me whether they see the same problem or not 🙂

  • If users share tasks, they are usually admins and may see all tasks anyway. You have special requirements.

    Entitling standard users to see/start other people’s tasks was crippled in 2016/Win10 and later versions, yes.

    If I want a standard user to be able to run a “foreign” task, I use the method I documented over here: How to empower restricted users to execute defined administrative tasks | Experts Exchange (experts-exchange.com)

  • Hey Joe.

    Boot Windows Setup, it will not ask your for any credentials. Will edit my tutorial accordingly.

  • @Water Lover
    Yes, isn’t that nice… they committed the change back in October and document it now, almost 4 months later. Found the same today, just came here to add it 🙂

  • Hi.

    Psexec does not need to be installed. Extract it from pstools, follow the given steps, report what you see.

  • Is it necessary to point out that the script itself needs to be whitelisted? You will have whitelisted a lot of scripts (like those in sysvol) and it should be obvious that this script needs to be among them. Best would be to digitally sign it with a whitelisted signature.

    Can you tell me why you think the script is (sometimes?) unable to delete the old configuration? Have never seen it failing to do that. Can you offer reproducible steps to make it fail?

    About 1) – what’s the problem here? Again I don’t understand what could possibly go wrong at your side

  • Enforcement mode configured to “enforce rules” within all sections (exe, script, MSI) of the GPO?

  • Ok, enough trying to say for sure.

    With Win10 22H2 and 11 22H2, you may use GPOs to control Applocker without my script. No matter if upgraded or clean install, it works. Don’t forget that standard applocker relies on the server “appidsvc”, so your GPO needs to change the startup type of that service to automatic.

    [yes, earlier I wrote that it didn’t work on 22H2 – the service wasn’t active]

    Will edit my article accordingly.

  • I made two attempts:

    On Win11 Pro 22H2 (clean install) AppLocker works out of the box without my script.
    On a VM with Win10 Pro 20H2 it didn’t work and after upgrading that to 22H2 (19045.2364), it still does not work.

    Will do further attempts with 11 22H2 when upgraded from 11 RTM and 10 22H2 when cleanly installed.

  • Hi Brandon.

    I would expect every comfortable solution to have a downside, security-wise.
    And that should be considered as well.

    For example: how secure are security question? NIST no longer recognizes those as an acceptable authenticator by SP 800-63.
    As your screenshot shows, those can be combined with SMS verification and push notifications and so on, but who is able to tell how secure this is against abuse? Try to put a number to it, that will be hard. Ideally, every pw reset system needs to be as secure as the pw itself; providing reset options should make it easier for an attacker to steal an identity, so giving an estimate of how secure this combination of reset verifications is, should be mandatory.

    Furthermore, I would like to know whether this software works with passwords only or whether it can also reset forgotten SmartCard PINs (for windows authentication).

  • Walter, David…
    Say, how funny is this… all these years, it didn’t work on pro. Here comes my scripted solution for pro, BAM, 6 months later, it works out of the box.

  • That would be astounding, indeed. I misunderstood at first 🙂
    So you tested this without using my script and things that you define in gpedit.msc get blocked?

  • Walter, this works on all Win10. Tried successfully on 21H2 Pro as well. So I am not sure how your gpedit.msc looked like, but surely that was a problem at your end.

  • The numerical recovery password does not depend on the hardware, it works anywhere, also when the drive is cloned to a new machine.

  • Load More
© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account