In my device policy, there is a property called "encryptionPolicy" (ref)
What is the purpose of this policy on the device?
How do I verify that it was applied?
There are 3 possibilities of values for this policy:
ENCRYPTION_POLICY_UNSPECIFIED
ENABLED_WITHOUT_PASSWORD
ENABLED_WITH_PASSWORD
But I don't know how to verify the application of that.
EncryptionPolicy is used to determined if encryption for the device should be enforced.
The level of encryption required to remain compliant depends on the value set by the policy documentation
ENCRYPTION_POLICY_UNSPECIFIED - (default) This value is ignored, i.e. no encryption required
ENABLED_WITHOUT_PASSWORD - Encryption required but no password required to boot
ENABLED_WITH_PASSWORD - Encryption required with password required to boot
If the device fails to comply to the policy set or if the device’s encryption state does not match with the encryptionPolicy by default compliance rule android device policy will immediately block usage of the device or work profile by default.
To check the encryption state of your device remotely, you can use device reports (specifically encryptionStatus).
To verify that if your device is encrypted locally on your android device (depending on your android device) you need to go to settings > security > encryption and credentials , and check the status if it is encrypted
Related
Is it possible to push certificates to a device, per device basis? I know you can set up certificates per policy, but I would need to set a different certificate per device (don't ask me why, the client wants it). If that is not possible is it possible to send any kind of data to a specific device?
P.S.
I have created my own EMM with android management API. I set up all the policies, added some commands that can be used per device, and I made a portal where the client can see all the devices. This is the only thing left I can't figure out if it's possible.
Unfortunately, it is not possible to have a different certificate per device with the same policy since the certificate is set up in the policy. Also it is not possible to send different data for each specific device using the same policy.
How are the following settings, located under Computer Configuration >> Windows Settings >> Security Settings >> Local Policies >> Security Options, related:
Interactive logon: Number of previous logons to cache (in case domain controller is not available)
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount
determines whether a user can log on to a Windows domain by using cached account information
Network access: Do not allow storage of passwords and credentials for network authentication
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\DisableDomainCreds
determines whether Credential Manager saves passwords and credentials for later use when it gains domain authentication
Is CachedLogonsCount just a more fine-grained policy, with DisableDomainCreds the same as setting CachedLogonsCount to 0?
CachedLogonsCount controls how many previous local logons are cached locally, so the user can sign-in to the machine in case the domain controller is unavailable. Very important difference: Windows does not cache the actual credentials, only a hash used to verify the password. This means even compromising the stored information does not give access to any domain credentials. Reference.
DisableDomainCreds controls if the actual credentials are cashed so a user can access domain resources without re-authenticating during their session. If you enable this policy, a user will be force to re-type their password every time they access a network resource, e.g. a network share. This functionality stores the actual credentials. Reference.
Two answer your question: No, these are two different mechanisms with different goals.
I used the Configure encryption types allowed for Kerberos in a KDC on Windows Server 2012 R2 for few times but now it's disabled. I don't know why or how to enable it. Help will be appreciated :)
The Disabled Configuration Panel
A group policy is present that sets this value.
You cannot override a group policy with the local policy, so that means you need to either remove the group policy or update it to include the necessary encryption types.
There are different keys for iOS(Client Key), Android(Client Key) and Windows Phone(.NET Key).
What's the purpose?
From my understanding (which isn't infallible), these keys are used so Parse can know what type of platform is connecting to which application.
Different platforms have different communication protocols, so Parse needs to know how to appropriately communicate with you.
Additionally, you don't want anyone to connect to you app. The id ensures that you're connecting to the right app. The key guarantees that it's you, and identifies your platform.
Application ID : Used to uniquely identify your application
Client Key : Used for Android and iOS connections
Javascript Key : Used for JavaScript connection
.NET Key : Used for Windows apps connections
Rest API Key : Used for Rest API connections
Master Key : Used for Rest API connections
Note: The Master Key does not adhere to object-level permissions, while the other keys do.
I found most of this from navigating to my App's settings page and clicking on keys.
Application Id -This is the main identifier that uniquely specifies your application. This is paired with a key to provide your clients access to your application's data.
Client Key - This key should be used in consumer clients, like the iOS or Android SDK. It adheres to object level permissions.
JavaScript Key -This key should be used when making requests from JavaScript running on a user's machine. It adheres to object-level permissions.
.NET Key - This key should be used when making requests from a Windows application. It adheres to object-level permissions.
You can also check here.
Open your Parse account settings then open keys section and click question mark icon.
I'm trying to get a certificate for myself, paying $200 to get it. Before I go buy it, does anybody know if installation of a kernel mode driver (that requires the code to be signed) has to have network access, how does it verify the authenticity? Etc.
Network access is not needed. The authenticity is verified by checking the digital signatures and certificates themselves. Network access is only used to update certificate revocation lists (in case any certificates have been revoked), and an operation won't fail just because the CRL couldn't be updated.
You don't need to buy a certificate to test Windows drivers, you can turn on Test-Signing mode. Check out http://msdn.microsoft.com/en-us/library/windows/hardware/ff547660(v=vs.85).aspx for more info.