Is it possible to do at least one of the following:
1) Detect a setting of a Local Security Policy (Accounts: Limit local account use of blank passwords to console logon only)
2) Modify that setting
Using Win32/MFC?
Well, I think I figured out how to do the first part (detecting this setting). It's actually located in the registry:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
the key is "LimitBlankPasswordUse", if it's 1 then it's Enabled, otherwise Disabled.
So, reading that will at least show me if I need to tell the user to modify it or not. I doubt I can change it though...
I've been down this road before and ended up with:
http://groups.google.com/group/microsoft.public.platformsdk.security/browse_thread/thread/63d884134958cce7?pli=1
I was able to configure User Rights Assignments using the Lsa* functions in advapi32.dll but could never work out how to configure Security Options.
This may be of help though:
http://www.windowsdevcenter.com/pub/a/windows/2005/03/15/local_security_policies.html
http://support.microsoft.com/default.aspx?scid=214752
You could customise a template then run regsvr32 %windir%\system32\scecli.dll from inside your code.
Not elegant but might be a way.
Related
I am running a windows 2016 server, we are running IIs 10 on it and i need to be able to assert if there is an AppPool setup before i deploy a website. If it doesn't exist i need setup the AppPool with a specific user and password.
All of this is done using a release agent through Azure Devops.
The agent is running as a NON-ADMIN, and i all accounts involved are running as NON-ADMIN. I have no intention at all to run any admin accounts, for security reasons i want to give least privildges to all accounts involved.
when i try to set up a AppPool using appcmd.exe i get the error msg:
KeySet does not exist.
When running everything as admin it works (and i have absolutely no intention in running any of this as admin).
What i have tried:
i have added the non-admin account to the IIS_IUSRS group.
Made sure that the user has read permissions to the file: 76944fb33636aeddb9590521c2e8815a_GUID in the %ALLUSERSPROFILE%\Microsoft\Crypto\RSA\MachineKeys folder.
i have tried everything here: Error when you change the identity of an application pool by using IIS Manager from a remote computer
anyone that actually knows the cause of this problem?
UPDATE:
Microsoft clearly recommends that agents should be run using service accounts, which i am doing and i have no interest in giving build agents administrative rights to 1000s of servers when they clearly don't need that kind of powers actually. I want to restrict their powers to only be allowed to do what they need to do. I can't believe that giving everything admin is apparently the norm.
After a lot of googling, and i mean A LOT. I managed to solve this. And let me say, that it baffles me that "least privileged accounts" is not common practice in the Microsoft and windows world.
I found this excellent post by InfoSecMike locking down azure devops pipelines.
And we both have the exact same requirements and opinions on this topic.
You CLEARLY don't need admin rights to update IIs configurations (because that would be insane, right!?). The IIs configuration API does not care what rights you have, what you do need is access to certain files. But this is not documented. Microsoft themselves, just for simplicity, tells you that you need to be admin, and buries all the details really deep in documentation when this should be best practice. Also what amazes me is that no one questions it.
What you need is the following:
full access to C:\Windows\System32\inetsrv\Config
full acccess to C:\inetpub
read access to three keys in C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\
6de9cb26d2b98c01ec4e9e8b34824aa2_GUID (iisConfigurationKey)
d6d986f09a1ee04e24c949879fdb506c_GUID (NetFrameworkConfigurationKey)
76944fb33636aeddb9590521c2e8815a_GUID (iisWasKey)
The 2 first bullet points can be obtained if you make sure your service account is a member of the group IIS_IUSRS.
This group will not give you access to the keys. You need to manually give read permissions to these 3 keys to the agent user.
If you don't give access to these keys you will get the obscure error message
Keyset does not exist ( exception from HRESULT : 0x8009000D)
Which is an incorrect error if you ask me as it should be an IllegalAccessException with proper reason telling you that you don't have access to read the key because the keys are there, they do exist (nice code microsoft, maybe you should open source this so we can fix).
I'll leave with this quote from infosecmike.
The goal was to lock down the permissions of the Azure Pipeline Agent {...}. I started Googling, pretty sure I would find a way to achieve this goal. I didn’t. It’s surprising to not find an answer about this. It seems like the principle of least privilege does not apply anymore in a devops world.
This is why i prefer Linux over Windows. This is a simple task there.
I'm working on a System Service project with SYSTEM privilege (cleaning utility)... It does not interactive with any user interface.
My goal is to check files in "Desktop" and "AppData" folders for any user that exists on the PC.
I'm using NetUserEnum() to get the user list on the PC. Then I want to get the path of each user's Desktop and AppData with SHGetKnownFolderPath(), but I can't find a way to get each user's access token for SHGetKnownFolderPath(). Without a token defined in SHGetKnownFolderPath(), it returns the path for SYSTEM and not specific users.
Q1. How can I get the token of each user for SHGetKnownFolderPath()?
Q2. If no answer for Q1, is there any documented way to get the desktop & appdata path of each user in the PC?
I understand this can be achieved with dirty way ---> Registry key with some string replacement. However, the Registry key method is undocumented, which may easily break in future updates to Windows.
Edit Update:
#RaymondChen Thanks for pointing out that some user profiles may not exist. Also,
About Q1 : #Remy Lebeau provides a solution with LogonUser/Ex(),login to each user with their credentials,might be the only answer that fits the need of Q1.
About Q2 : There might have no documented way to achieve this. The only method might have to stick with Windows Registry (Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders) , as #Remy Lebeau and #Olaf Hess said. I tried to dig more information on Microsoft Community Forum and I got Microsoft would never allow access other users' profile with their native API for security reason. They do not provide APIs that can possibly violate the security rules. Each user profile can only access by its credentials.
btw, I totally understand that "Cleaning utility" aka "Windows-breaking tool", especially when the tool is not being well codded(ex. compatibility problem). For the sake of avoiding to make it become a totally Windows-Destroyer, I tried to use more documented API as possible.
For Windows Vista with SP1 / Server 2008 and better you can query the existing user profiles using the WMI class Win32_UserProfile. This allows you to retrieve the profile path and check whether it is a local or roaming profile and to get status information. The rest (retrieving the paths to APPDATA, DESKTOP, etc.) is likely going to involve reading values straight from the registry (HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders or HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders).
I'm working on a tool that generates .rdp files and then invokes them using Microsoft RDP Client. This tool is running on Mac OS.
Everything works well, the only problem is that I can't figure out of how I can generate 'password 51:b' field properly. On Windows this can be done easily by using CryptProtectData method from Crypt32.dll library. How can I do the same on Mac.
Another option could be to use "rdp://" URL scheme, but it doesn't seem allow to pass password this way.
So the question is how can I implement auto-login on Mac if I use third-party RDP client.
As far as i know you can't. You can however create a "User Account" and a Server configuration and add both to the client. The connection will then be visible on the main window and you just need to double click it.
To do so, you need to add the password to the Keychain, use /usr/bin/security to do so from a script. It needs to be a generic-password and saved in com.microsoft.rdc.macos. Also be sure to generate an ID according to the RDP Clients scheme, like BFF77777-7777-7777-7777-777777777777.
You may also set the permissions to read that key using /usr/bin/security and set-generic-password-partition-list specifying the right teamid (UBF8T346G9) and again com.microsoft.rdc.macos. You need the admin password to do this step.
Then you can alter the RDP Clients config file, which is a .sqlite file located at /Users/$(whoami)/Library/Containers/com.microsoft.rdc.macos/Data/Library/Application Support/com.microsoft.rdc.macos/com.microsoft.rdc.application-data.sqlite. Add the user configuration in the ZCREDENTIALENTITY table and make sure the ZID matches the one added to the keychain.
To add a server configuration you need to alter the ZBOOKMARKENTITY table. Just add a configuration by hand using the UI and look at the table to get a feeling of how it needs to be setup. Basically you link your user configuration with the server configuratio by making sure that ZCREDENTIAL in ZBOOKMARKENTITY matches Z_PK in ZCREDENTIALENTITY of your user configuration.
I know the answer is a bit late, but it may give you a starting point. This will however not fully automate the process, you will still need to go to the UI and double click the connection you want to use.
i have a MSI installation package that is installed as SYSTEM User and adds an active setup entry to the registry. This setup makes sure when a new user(new = that has not executed this setup until now) is logging on msiexec adds all missing registry entries.
In the MSIEXEC i need to do a net use to mount the users home directory. This cannot be done as system user and needs to be done in the user context.
However i seem to be completely unable to detect that the setup is currently running on the user context. Thats why i thought it would be nice to give additional parameters to the StubPath in the active setup entry. I tried NETUSE=1. This however did nothing. The setup just ignored this parameter and uses the parameter given during installation. So NETUSE stays 0.
Any ideas what kind of condition i could use for my custom net-use action?
Why is an MSI mounting a users home directory? I would write a small utility to do all this work and just have the MSI put it in the Run registry key. Install once per machine as System and then when the user logs in the utility gets called and does whatever per-user work you need to have done.
If the installer legitimately needs to populate per user registry data then that is fine to continue the active setup pattern.
You can try to use your own custom action configured to run only when the LogonUser property is different tan SYSTEM.
I'd come to this conclusion through experience and various things I've read on this internet, but in stating it to a co-worker, it seems illogical. Can you verify the following statement is true, or provide a counter to it?
On Vista/Win7, two standard (non-elevated users) cannot read/write the same location in the registry.
On Vista/Win7, two standard (non-elevated users) cannot read/write the same location in the registry.
This is a false statment
On Vista/Win7, two standard (non-elevated users) cannot write the same location in the registry in the default configuration.
But this is true. By default, users only have write access to their own hive (HKEY_CURRENT_USER) and read access to the machine hive (HKEY_LOCAL_MACHINE).
If you want to configure a location where any user can read and write, you can certainly do by configuring a key's ACL, as #Dark Falcon said. A good place for this is somewhere inside your application's key in HKEY_LOCAL_MACHINE, and at install time (when your installer has elevated privileges to do so).
That would be incorrect. A registry key can have an ACL specified which allows any user, elevated or not, to write to it. By default, I am not aware of any keys which have this configured, but it certainly is possible.