I have a Cocoa application on OSX, which manages FileVault Disk Encryption on behalf of the user and reports back the recovery key to a server once the recovery key is generated. However, if the user changes the recovery key using 'changerecovery' command, is there anyway to listen to this event and obtain the recovery key so as to update the server?
As an alternative solution, have you considered using an institutional FileVault recovery key? With this method, you create a single key, install it on every machine that you manage, and then you can use that key to unlock the machine. This key is independent of the user's own recovery key.
There are directions here to create and deploy an institutional key: https://support.apple.com/en-us/HT202385. In addition to the manual deployment steps described in that support document, you can automatically deploy and enforce your institutional key using macOS/OS X Server Profile Manager so that it cannot be removed by the user. Instructions to do that are available here: http://impdossier.blogspot.com/2015/12/enable-file-vault-by-profile-manager.html
Related
I haven't logged on to my EC2 recently in a few months. Last time I did, it seems like the RDP file that I downloaded had the password in it. That laptop died.
Today, it seems like AWS/EC2 has changed how things work. I'm able to download the RDP file, but it is prompting for a password. When I try to decrypt the password, it wants me to paste or browse to a file on my disk, which I don't have.
Is there a way to re-download my key info? On security then "Key Pairs", I see the key for this server. Can I download that to my disk, or open it somehow?
I see these steps, but they look overwhelming, i.e. I don't have time for that now; I have real work to do:
https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ResettingAdminPassword_EC2Config.html
I was able to create a new key pair, but not sure if I can associate it with the instance.
When I click "Get Password" this screen appears:
UPDATE 1: I did find my .pem file, so I was able to use that to logon.
Had I not found it, what would I do?
UPDATE 1: I did find my .pem file, so I was able to use that to logon. Had I not found it, what would I do?
Not much really! This is by design. AWS doesn't store your encryption key, and this prevents AWS personnel to access your instance. That's why you get such an ominous warning when pem file is generated: this is your one and only opportunity to see it - don't lose it.
That said, there are several however.
If you changed your Windows password in windows, or created a new AMI and launched a new instance from it - the pem file won't really help. You can probably create 2 administrator accounts; so if one forgets their password, you can reset it with another one.
Second - if your EBS is not encrypted, you can detach it, launch another instance, and attach EBS to new instance. You won't get your instance back, but you will get the data from that drive.
Finally, the "overwhelming" steps from the link that you posted. Follow good security posture, and you won't need them. But if you get sloppy, it may become your real work... better than polishing a resume...
I am creating a sample Android application using Xamarin forms. I generate a unique ID randomly for that particular device when the User Install the app. I stored the value in Shared preferences/secure storage using Xamarin.Essentials just to check the persistence. It persists the data when I login and logout the app. But when uninstall and install the app, the data is not persisting, rather a new ID is created. Could anyone help me to solve this issue. I am not sure whether this can be achieved or something I am doing wrong. Do I need any additional setup to be done on the device?
Uninstalling the application will cause all Preferences to be removed.
https://learn.microsoft.com/en-us/xamarin/essentials/preferences?tabs=android
If you want to permanently save user ID of that device, you need to store that key on a server once you first generate it. Shared preferences only works for client side and it is related to the memory of the app, once the app is uninstalled, shared preferences are cleared.
Preferences will get deleted once you uninstall the application.
However there could be 2 approaches for your scenario,
Approach 1
Store a unique file with a unique name in some folder at a public location.
Store the data in that file which you want to persist
Re-sync data after uninstall and install from the file at a public location.
Disadvantage : It can be manually deleted by the user and in that case it would be considered a fresh install.
Approach 2
There are 2 kinds of ids identifiable for an android device.
Secure.ANDROID_ID
This is unique per physical device. After boot of each android device,
for the first time, a 64 bit random number is generated and maintained
for a lifetime (unless the device was factory reset). After Factory
reset it could change.
UUID
This is a unique number for an app per installation. Every time your
app is installed android generates this unique id per installation.
So, to address your requirement,
No need to generate a unique random number per installation yourself.
You can use UUID.
After the application is installed, you can store a Secure.ANDROID_ID on your server and the all the data corresponding to that device which you want to persist in your database on server.
On re-installation and the application start up those data can be re-synced using the ANDROID_ID.
Disadvantage : Upon Factory reset, the ANDROID_ID could change and it could be considered a fresh install.
I'm trying to lock out a Registry from being altered by the System. When Windows 10 Updates push, it set 90% of out registry Hive data back to Factory Default. Which get annoying to fix after patching. The issue is the system is creating subkeys under certain keys that are wrecking configs. I've tried locking out the ability to write subkeys from the system with the the following:
//Sample Key : HKLM\Key1\Key2 (Key1 is the Key in question)
• Took Ownership (owner = localhost\administrators)
• Disabled Inheritance
//Security Config (Allow)
ALL APPLICATION PACKAGES = Read
CREATOR OWNER = Special
SYSTEM = Read
ADMINISTRATORS = Read
USERS = Read
• All Subkeys are mirrored through the GUI
//Notes
I've done this with several different attempts, but after patching is complete, the Windows is back to factory. I noticed TrustedInstaller is not on the list, but this should deny that account correct?
Thanks in advance for any help. :)
I am windows user and wanted to use a spot instance using my own EBS windows AMI. For this I have followed these steps:
I had my own on-demand instance with specific settings
Using AWS console I used option "Create Image EBS" to create EBS based windows AMI. IT worked and AMI created successfully
Then using this new AMI I launched a spot medium instance that was created well and now running with status checks passed.
After waiting an hour or more I am trying to connect it using windows 7 RDC client but is not reachable with client tool's standard error that either computer is not reachable or not powered on.
I have tried to achieve this goal and created/ deleted many volums, instances, snapshots everything but still unsuccessful. Doesn't anybody else have any solution to this problem?
Thanks
Basically what's happening is that the existing administrator password (and other user authentication information) for Windows is only valid in the original instance, and can't be used on the new "hardware" that you're launching the AMI on (even though it's all virtualized).
This is why RDP connections will fail to newly launched instances, as will any attempts to retrieve the administrator password. Unfortunately you have no choice but to shut down the new instances you've been trying to connect to because you won't be able to do anything with them.
For various reasons the Windows administrator password cannot be preserved when running a snapshot of the operating system on different hardware (even virtualized hardware) - this is a big part of the reason why technologies like Active Directory exist, so that user authentication information is portable between machines and networks.
It sounds like you did all the steps necessary to get this working except for one - you never took any steps to cause a new password to be assigned to your newly-launched instances based on the original AMI you created.
To fix this, BEFORE turning your instance into a custom AMI that can be used to launch new instances, you need to (in the original instance) run the Ec2ConfigService Settings tool (found in the start menu when remoted into the original instance using RDP), and enable the option to generate a new password on next reboot. Save this setting change.
Then when you do create an AMI from the original instance, and use that AMI to launch new instances, they will each boot up to your custom Windows image but will choose their own random administrator password.
At this point you can go to your ec2 dashboard and retrieve the newly-generated password for the new instance based on the old AMI, and you'll also be able to download the RDP file used to connect to it.
One additional note is that Amazon warns that it can take upwards of 30 minutes for the retrieval of an administrator password after launching a new instance, however in my previous experience I've never had to wait more than a few minutes to be able to get it.
Your problem is most likely that the security group you used to launch the AMI does not have RDP (TCP port #3389) enabled.
When you launch the windows AMI for the first time, AWS will populate the quicklaunch with this port enabled. However, when you launch the subsequent AMI, you will have to ensure that this port is open for your security group.
I am using SecKeyGeneratePair to create a pair of keys, but I cannot figure out how to set access controls. I want to set it so that the second time my app wants to use it, it doesn't ask the user for permission.
It probably too late, but anyway. Check out code sample in Modifying the Access List of an Existing Keychain Item topic of Keychain Services Tasks for Mac OS X manual.
Also, if it was your application that created the keys, it should have access to them.