When I want to check in my registry for changing keys for bitlocker I don't seem to have this location:
HKLM\Software\Policies\Microsoft\FVE
The FVE map isn't there. So I also can't change these keys with PowerShell.
Its a local computer, not in a domain.
Anyone know how I can solve this?
You need to Edit local group policy. Located here:
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Choose drive encryption method and cipher strength
You will also need to install the MBAM Client in order for that reg hive to appear.
Once you enable the GPO and install the MBAM Client you will be able to change what you want within the registry. However, local group policy works just fine in this case.
Related
In Windows XP, I'm going to add a new user with a simple password. It prompts that the password does not meet the password policy requirements. I've not set a policy!
Then I found that i should use gpedit.msc to change this policy. But it's disabled and I'm unable to change the default policy. I don't know how to change this policy.
Can you use Start -> Run -> secpol.msc, and then navigate to Account Policies and then Password Policy and change it there?
If not, then maybe you can do this by editing the registry directly using this:
Set strong password policy in Windows XP
Oh, I found it! The computer was joined to a domain. So I couldn't create a user with a simple password, even in the local Windows. I left the domain and the fields got changeable!
Microsoft is always weird.
I am encountering several situations where, in a Chef recipe with powershell_scipt, a command appears to fail, whereas if I run the same command in powershell outside of Chef, the same command works.
The two in particular are "regedit", which I am trying to use to set a key for app compatibility and the other is "net use z:...." to created a mapped drive. Both of these seem to work fine if I run them in powershell, but if I use them inside a recipe inside powershell_script, they don't appear to do anything.
So I'm wondering is this because Chef runs commands that are inside powershell_script at some lower privilege level?
Also if so, how do I change it so that the regedit and net use would work?
Thanks,
Jim
EDIT 1: This seems to work for adding the registry entry I needed:
registry_key "HKEY_CURRENT_USER\\Software\\Microsoft\\Windows NT\\CurrentVersion\\AppCompatFlags" do
values [{
:name => "{2b9034f3-b661-4d36-a5ef-60ab5a711ace}",
:type => :dword,
:data => 00000004
}]
action :create
end
That prevents the compatability popup that I am getting when we run the Sharepoint installer.
EDIT 2: I hope that this is ok, but for the record and more visibility and hope that I remember this, I found this re. mapping drives in Windows and Chef:
Mount windows shares on a windows node with Chef
and:
https://tickets.opscode.com/browse/CHEF-1267
I haven't tried that yet, but that seems like the answer to my drive mapping need.... hopefully..
The chef client service runs as Local System (SYSTEM) by default.
In Windows, that user has full privileges on the local system, like root basically, but on the network it authenticates as the computer object.
So it you are trying to use regedit to change something in for example HKEY_CURRENT_USER then you need to remember that the code will not see the same "current user" as you will when you run it in interactively. Also, regedit is an .exe; you should really do what you need through the PowerShell providers or .Net objects.
For net use you are trying to map a drive. It's likely that the computer account doesn't have the rights to the share that your user has. Again, net.exe is a separate executable. net use maps a drive to a drive letter (usually) and you shouldn't be doing that in a configuration script, in my opinion. You should access the UNC path directly, but either way I still think that you're probably running into a permissions issue here.
You could change the credentials of the service to use a user account that has all the rights you want, but before doing something like that you should consider changing your workflow to not need that.
As I've explained in my other question, I'm busy setting up a PowerShell module repository in my enterprise.
My plan is to have a master repository (r/w access to a limited group of people) and slave repositories (read only access to everyone). I need multiple repositories because clients are located in different security zones and I can't have a central location reachable by all clients.
For this reason, I need to configure the PowerShell profile of the clients so that they can point to the correct repository to find the modules. I would like to define a $PowerShellRepositoryPath environment variable for this purpose.
Also, the profile needs to be customized in order for it to execute a script located in the repository (thus where $PowerShellRepositoryPath points to) when PowerShell starts (my goal here is to automatically add the latest module versions to the PSModulePath of the clients on startup).
We have a mixed environment with domain members and stand-alone servers in different network zones.
How would you proceed? Is it possible to push that variable and the profile via a GPO for domain members? Would customizing the $Profile variable via GPO be an option?
What about the standalone servers?
Edit:
I think that for creating the environment variable, I'll just use a GPO to create it and use it in PowerShell via $env:variableName. For non-domain situations, I'll probably have to use a script though..
I am not sure about pushing $profile via GPO. But, I'd simply put a logon script that copies the profile script from a network location based on the user's group/security membership.
Well if you're going to change the path to the modules, I'd have a file in the repository (say current.txt) that has the name for the current module (or current file path, whichever you are changing) in it. Then have the $profile script read the content of that file, and set the variable based on the contents. This way you don't have to screw around with updating the profile scripts, just update the central repository current.txt file with the path (or partial path, the part that changes, or filename or whatever), and when it replicates to the client repositories, all powershell profiles get updated with the latest modules when the profile script is executed.
Out of curiosity, why not just overwrite the module files in the client repositories with the latest version? If you did it that way, all clients would always have the latest versions, and you wouldn't have to update the $profile scripts.
Alternately you could always write another script to replace the $profile script on all machines. I think the first route I suggested would be the cleanest way of doing what you are after.
As far as the GPO thing goes, I don't believe you can do this. There is no GPO defined to control what is in the profile script. I would say you could maybe do it with a custom ADM file, but the profile script path is not controlled by the registry, so no go there.
Is it posible to read a certificate out from registry without booting windows, if you know login credentials and computer name.
I have writen a little tool which automate copying of data from standard windows user folders like my document.
This tool is then part of live linux distro which we use to copy users data when we making transition from previous to our IT. Only problem is that we can't get certifikates this way and i'd like to solve this, if it's possible.
This program can read from the Windows registry Hives under Linux: http://pogostick.net/~pnh/ntpasswd/ .
I don't know where the certificates are stored or in what format, but they're in the registry somewhere. Check MSDN for information or do a registry diff before and after storing a cert.
Betcha they're DER-encoded binary keys.
Can any script or setting be written (autorun file?) to disable formatting of a USB Flashdrive? (Win XP, via Windows Explorer > Format)
I'm aware of write-protection, but I don't want to completely prevent modifying files, instead something like what a Group Policy setting could do?
Edit: Really what I'm asking for is a registry setting or else that I can modify on USB drive startup to tell Win XP not to format drive X:
Format the things as NTFS. That should give you sufficient security. You need admin rights to the volume to reformat the USB stick. Anyone with those rights can by definition disable any protection you could enable. If you allow Everyone to create and modify files in the root directory and below, users can still write files as demanded.
Registry key 'MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\AllocateDASD' restricts the formatting and ejecting of external drives (see this helpful Microsoft spreadsheet full of registry keys that the Group Policy editor controls).
Set it to 'Administrators' or another group which you can trust not to go formatting where they shouldn't.