I'm trying to protect our Win10Pro Dell laptops using Bitlocker.
We'd like to add the initial PIN request.
We are following a lot of online articles enabling the Require additional authentication at startup key and setting Configure TPM startup Pin to Require startup PIN with TPM.
After that, I typed the command
manage-bde -protectors -add c: -TPMAndPIN
but we always receive the error:
ERROR: An error occurred (code 0x80310060):
Group Policy settings do not permit the use of a PIN at startup. Please choose a
different BitLocker startup option.
Other way was by the command line command:
manage-bde -on c: -UsedSpaceOnly -RecoveryPassword -RecoveryKey e: -TPMAndPIN 123456
but again the 0x80310060.
OK. Here is what you need to do. Before I start with the details, let me highlight a few differences between your environment and my own:
Details below are for Windows 7 Ultimate
Details below are for TPM + startup key instead of a startup PIN
These differences should be minimal, and you should still be able to get the outcome you want.
Configure Group Policy
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives
Select:
Require additional authentication at startup
Choose the following options:
Configure TPM startup: Do not allow TPM
Configure TPM startup PIN: Do not allow startup PIN TPM
Configure TPM startup key: Require startup key with TPM
Configure TPM startup key and PIN: Do not allow startup key and PIN with TPM
Encrypt the drive
At this point, you should be able to go to
Control Panel > BitLocker Drive Encryption
and use the wizard. (If you have setup your Group Policy settings wrong, when you try to encrypt the drive, you will get a message in the encryption dialogue box saying that your Group Policy settings are in conflict, and you need to change them.) Otherwise, you should be able to save a startup key (or, in your case, enter a startup PIN) and continue with drive encryption.
Limitations
When I first started researching this, my goal was to use a startup key exclusively, without using the TPM at all. The Microsoft documentation was pretty clear from the start, that to do that, you must use the command line tools. The Control Panel wizard will not do what you want. (While I am very much at home on the command line, Windows OS drive encryption is new territory for me. I wanted to stay on a well-traveled road.) The method above lays out how to use the TPM + startup key. You should be able to modify this slightly for your own needs, using the TPM + startup PIN.
Source
Lastly, here is the excellent article that guided me through setting up Group Policy. The article walks you through how to setup BigLocker with the TPM + startup PIN + startup key. All the command line calls are listed; I haven't tried any of them, but maybe you will find them useful for a managed installation.
https://mrhorn.com/wp/posts/bitlocker-with-tpm-pin-usb-startupkey/
Related
I would like to restrict some functions in a user written server add-in for certain users or groups.
Question: Is it possible to get (via an API) the user name who is sending a "Tell" command from a remotely connected server console?
Example:
Tell AddinName Command (issued remotely by Hotline User)
Tell AddinName Command (issued remotely by Admin User)
The remote console (and therefore the "Tell" command) is available to both users, but a subset of commands should only be allowed to authorised users (e.g. Group in Server Document->Security).
Is the user name (entering the "Tell" command) available (e.g. in the MessageQueue)?
I know that internally in Domino there are already some restriction possible to commands issued at the console.
The session.getCommonUserName() always returns the server name (since the add-in runs in context of the server).
Thanks for any pointer or ideas.
Andy
I believe that the answer to this is no, and it would not be advisable to implement tell commands that you can't trust to all authorized administrators.
If you really do need to confirm a user identity for a command, you're going to need to use database to queue the commands. I.e., you could build an application that stores the commands in documents in a database with a restricted ACL. Your addin code can use an Extension Manager hook to monitor the database for changes and read new documents when they appear, or you could have your application use NotesSession.SendConsoleCommand to issue something like 'tell myAddIn process ' to wake up your addin and give it the noteid of the document it just created. If you need to protect against people with full access admin rights overriding the ACL, your application could digitally sign the documents and your addin could verify the signatures.
I turned off (set 0 value in "Enabled") AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes in windows server 2012 R2 registry (hosted on aws).
Then I used command "Restart-Computer" and cannot to login via RDP to my server. How can I restore RDP connection ? and connection at all ?
Thanks in advance.
There is the answer from aws support:
There are 3 methods using which you can revert the registry changes. Request you to follow the Methods in a sequential manner if the current Method fails.
Method 1 - Connecting to the registry of the problematic instance from another instance in the same VPC and revert the changes. (You can launch a test instance temporarily in the same VPC if you don't have any existing instance (s) in the same VPC.)
1. Open Registry Editor from the working instance which is in the same VPC as problematic instance.
2. Click on File->Connect Network Registry.
3. Enter the FQDN of the server and Click on Ok.
4. Enter the credentials and Click Ok.
5. Now Expand the Remote computer (Problematic instance) hive and revert the changes.
Method 2 - Access the problematic instance using TightVNC.
1. Ensure that the non-working instance has IAM role assigned to it with Policy named "AmazonEC2RoleforSSM" attached to the IAM role. To create and Attach an IAM role See Link https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html & https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role
2. Now Install TightVNC on a working instance which is in the same VPC and subnet. Link to download TightVNC MSI: https://tightvnc.com/download.php 3. Right click on the MSI > Properties > Under the General Tab > Ensure the file has been Unblocked by Ticking the Unblocked check box.
4. Now copy the msi file on the problematic instance as well. Copy the MSI to C$ on the problematic instance (\\c$). For simplicity sake rename the MSI to TightVNC64.msi 5. Now go to https://console.aws.amazon.com/systems-manager
6. On a Left Pane, Under Actions, Click on Run Command.
7. Click on Run Command and Search for Command Document named "AWS-RunPowerShellScript".
8. Select AWS-RunPowerShellScript and under Command Parameters paste the below command:
Start-Process -FilePath "C:\TightVNC64.msi" -ArgumentList ("/q SET_PASSWORD=1 VALUE_OF_PASSWORD=YouSecurePasswordGoesHere SERVER_ADD_FIREWALL_EXCEPTION=1") -Wait -PassThru
9. Scroll down and Under Targets, Select the Problematic Instance.
10. On the bottom of the page Click Run.
11. Wait for command status to get successful.
12. Launch the TightVNC Viewer on your working instance and provide the IP/FQDN of the problematic instance followed by the credentials that you have provided under command in Step 8.
13. You will be connected to the Instance and can make changes in the registry.
Method 3 (Method will require Stop and Starting of the instance.)
1. For Detaching the Root Volume from the problematic instance and Attach it to the working instance request you to please watch video from 1:47 to 3:40 in following article:
https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
2. Open Disk Management Console (diskmgmt.msc) and Right Click on the Disk showing Offline status and Click Online.
3. Once the Disk is Online, Go to My computer and make a note of the Drive letter of the disk which you have attached.
4. Open Registry Editor and Select HKLM.
5. Click on File and Load Hive. Provide any name for eg. "Recovery".
6. Expand the "Recovery" key and revert the changes i.e. Enable the value for AES 128\128 cipher, and SHA, SHA256, SHA384, MD5 hashes.
7. Once all the changes are made, Select the "Recovery" Key and Click on File and Unload Hive.
8. Open the Disk Management console and take the disk offline.
9. Now for re-attaching the root volume to your problematic instance, request you to please watch video from 08:02 to 9:28 using the same link: https://aws.amazon.com/premiumsupport/knowledge-center/ec2rescue-windows-troubleshoot/
Additionally, first of all you should ensure that yuor IP-address in range of inbounds-rules of the failured instance.
in my case I, first of all tried to use amazon app "app2rescue" for diagnostic failured instance, bit it didn't show any helpful (did show only few possible issues with firewall, but it's not related to my issue).
Then I tried the first method - but I could not get access to remote registry (I assume that on the target machine was disabled "Remote registry" service).
And finally, I used the third method and it fixed my problem. During this operations I faced only one issue - before failure I was changing the currentControlSet, and when I attached volume to temp server, I was trying to find exactly it, but found out that currentControlSet is enabled only when this registry is used for current OS (when this registry works), so I found my problem-parameters (sha, md5 etc) in the controlSet001 instead of currentControlSet.
I want to install a TeamCity BuildAgend as a user. When entering my user credentials here:
I always get this error:
NOTE: My account (user) is Administrator with full permission!
How can I do this?
The error message says it does not have "enough rights to run as a service",
this is slightly different from just being an administrator.
Go to Control Panel> Administrative Tools> Local Security Policy.
Select Local Policies> User Rights Assignment.
Scroll down through the list of policies and look for Log on as a service.
Add the account you're using to the list of accounts with this right.
That should in theory be all you need to allow the service to run under that user.
The best powershell command that I have found for this is:
Grant-Privilege -Identity $SERVICE_USERNAME -Privilege SeServiceLogonRight
Requires use of the Carbon framework.
I'm a Windows 10 Home user and the steps above did not work for me, but the following did:
Enable gpedit.msc by running the batch file as explained here under Method 1: https://www.askvg.com/how-to-enable-group-policy-editor-gpedit-msc-in-windows-7-home-premium-home-basic-and-starter-editions/
Run gpedit.msc
Go to Local Computer Policy / Computer Configuration / Windows Settings / Security Settings / Local Policies / User Rights Assignment
Double-click Log on as a service
On the window that appears, click Add User or Group...
Enter your username and click the Check Names button
Your name will be modified, adding the machine name as the prefix. Click OK
Click OK on the Log on as a service Properties window to apply the change.
It is a little bit of a pain, but after doing that, I was able to continue installing TeamCity
Good day.
I am developing a program that will be used in a corporate environment by the end users. The application will automatically fix certain errors as soon as the user selects the application name, chooses the symptom or error message and clicking on the fix button.
The idea behind is to decrease the amount of calls we receive at the IT Service Desk (The company's personal Call Centre for IT Issues) and at the same time assist the end user by resolving the issue within a minute (versus waiting on the phone for up to 15 minutes or more).
I've am not yet allowed to upload an image of the application, but imagine a small'ish windows form with 2 columns; Aplication name and Synptom. The user will choose the application's name, click on the error message and click on the FIX button. This basically automates whatever we has IT Techs would manually.
The problem I'm facing is that some of the code is supposed to be executed with adminsitartor rights, eg. Stop and Start a given service, adding regsitry entries for Local Machine, etc.
Given the fact that none of the users will be allowed to have elevated rights and the fact that they need to use this application as a sort of "self-help" alternative without the need to call the IT Service Desk, is there a way to give a set of code "administrator permissions"? The application should NOT request the user to enter ANY passwords.
Regards,
Willem
No way, AFAIK: the model in common operating systems is process-centric, so that the process is given permissions that are then inherited by its code. You can elevate such privileges at some point, but that will be for the whole future life of the process (or as long as the authentication token for it ceases to be valid).
In windows the right way to do that is to employ a back-end service: at boot, you start the service called IT_Auto_Fixer_Back_End with high permissions (try to avoid Administrator, NetworkService or LocalService could be enough for you). When the app IT_Auto_Fixer_Front_End is started with USER privileges, it operates until it needs something with high privileges. At that point it sends a request to the service, that will do it.
If you choose this way, some important advices:
The IT_Auto_Fixer_Back_End must not become a backdoor! If you use TCP as form of communication with IT_Auto_Fixer_Front_End, make it listen localhost only and use SSL (yes!) to encrypt local traffic
It must not be possible to invoke arbitrary commands using IT_Auto_Fixer_Back_End. You need to enumerate the possible requests that could be made (i.e. a command like stop_mysql_service rather than accepting directly the string net stop mysql - the application logic will translate your string into the real OS command)
Every input from the user could be used to perform command injection. To prevent this, use the Windows API that requires an array for the command - this way if the user adds options to a command (i.e. the name of the service in net stop) they won't be interpreted as another command (common scenario: when accepting the name of the service as a parameter, a malicious user that tries to execute something like net start mysql ; net user /add hacker t00E4sy). Authentication and encryption will not help you against this, you must escape any user input that goes inside the command.
Sanitize your ENVIRONMENT by using the API that executes commands setting the PATH (and other relevant variables), so that the user will not be able to taint the PATH, executing C:\temp\net.exe instead of C:\Windows\System32\Net.exe
IT_Auto_Fixer_Back_End service should be authenticated: it should check every time if the request comes form the user by checking if the Kerberos token is valid (Windows => you get a very nice Kerberos environment for free!). This will prevent someone else to break into the machine, use SSL to connect to the localhost port and elevate privileges through your service
The above (authentication) still stands when something else (i.e. shared memory, windows sockets, a file, etc...) is used as communication channel between IT_Auto_Fixer_Back_End and IT_Auto_Fixer_Front_End
Life gets harder when you want to properly implement something dealing with multiple level of permissions...
I have an Okuma OSP Machine Controller running Windows XP.
By default it attempts to automatically log on when the machine is turned on.
We have changed the default administrator password and now the auto-log on fails every time.
How can I turn off this feature or update the password so that it succeeds?
Machine Types Effected: Any machine with P200 or P300 control running Windows-XP
4/1/2014: Confirmed the same applies to new OSP-300 Windows 7 controls
2/1/2015: There is another (easier) way to accomplish this on Okuma controls.
This can be done using a utility in the TOOLS directory called the "Auto Logon Setting Tool". This is perfect for anyone uncomfortable with editing the registry.
Tool location:
The utility:
Just choose the user you wish to to be logged on automatically, and click the "Register auto log-on" button.
This feature is enabled from the factory to allow users to get up and running quickly while still having the machine password protected. Because it is recommended to change the default password this is most likely a very common situation.
The automatic login behavior can be changed by editing registry settings.
Click Start, type "regedit" (sans-quotes) in the run box, and press enter.
In the folder structure in the left pane, navigate to the following folder:
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
To turn the feature OFF, change the key value of "AutoAdminLogon" to '0'
Similarly, the default user name and password can be changed by editing the appropriate keys to restore the functionality of the auto login feature.
Reference Microsoft Support article here.