Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2019-02-22) Getting Rid Of Self-Signed Certs In Intermediate CA Store

Posted by Jorge on 2019-02-22


In the case of ADFS servers you may end up with self-signed certificates in the Intermediate CA store. Those self-signed certificates are most likely root CA certificates and those should be move to the root CA store.

After running the “Export-AdfsDiagnosticsFile” CMDlet on the (primary) ADFS server and uploading it to ADFS Help – Diagnostics Analyzer you might see something like shown below

image

Figure 1: Self-Signed Certificates Reported In The Intermediate CA Store By The ADFS Help Tool

With PowerShell you can find self-signed certificates by checking certificates and see if the subject is the same as the issuer

Get-ChildItem <Certificate Store> | ?{$_.Issuer -eq $_.Subject}

image

Figure 2: Self-Signed Certificates In The Intermediate CA Store

First you need to identity if any self-signed certificate is not a root CA certificate. In that case you can most likely remove that certificate from the intermediate CA store.

To remove a certificate from a certificate store you can use:

Get-ChildItem <Certificate Store>\<Certficate Thumbprint> | Remove-Item

Anything left can be moved from the intermediate CA store to the root CA store. To do that you can use the following:

$sourceCertStore = "Cert:\LocalMachine\CA"
$sourceCertStoreObject = Get-Item $sourceCertStore
$targetCertStore = "Cert:\LocalMachine\Root"
$targetCertStoreObject = Get-Item $targetCertStore
Get-ChildItem $sourceCertStore | ?{$_.Issuer -eq $_.Subject} | %{
    $thumbprint = $null
    $thumbprint = $_.Thumbprint
    $cert = $null
    $cert = Get-Item $sourceCertStore\$thumbprint
    If (!(Test-Path $targetCertStore\$thumbprint)) {
        Write-Host ""
        Write-Host "Adding Certificate With Thumbprint ‘$thumbprint’ To ‘$targetCertStore’" -ForegroundColor green
        $targetCertStoreObject.Open("ReadWrite")
        $targetCertStoreObject.Add($cert)
        $targetCertStoreObject.Close()
    } Else {
        Write-Host ""
        Write-Host "Certificate With Thumbprint ‘$thumbprint’ Already Exists In ‘$targetCertStore’" -ForegroundColor Red
    }
    If (Test-Path $targetCertStore\$thumbprint) {
        Write-Host "Removing Certificate With Thumbprint ‘$thumbprint’ From ‘$sourceCertStore’" -ForegroundColor green
        $sourceCertStoreObject.Open("ReadWrite")
        $sourceCertStoreObject.Remove($cert)
        $sourceCertStoreObject.Close()
    }
}

image

Figure 3: Moving Certificates From The Intermediate CA Store To The Root CA Store

Have fun!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Advertisements

Posted in Active Directory Federation Services (ADFS), Certificates, PowerShell | Leave a Comment »

Temporary Post Used For Theme Detection (e88dce78-9d00-4b24-8c21-740601c6007b – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Posted by Jorge on 2019-02-21


This is a temporary post that was not deleted. Please delete this manually. (5d105060-0435-41fd-a0d1-b22eb8f1677e – 3bfe001a-32de-4114-a6b4-4005b770f6d7)

Posted in Uncategorized | Leave a Comment »

(2019-02-21) Code Snippets: Testing For Admin Credentials

Posted by Jorge on 2019-02-21


In your scripts you may need to test the current account used by the script for admin credentials, either local admin, domain admin or even enterprise admin. If you really want to be specific you may want to test if a user is a member of a specific group. In the latter case you use a group that was defined by you, hence the group name being targeted is specific and known. However, if you need to test being a member of the default admin groups in Windows or AD and you are in a global environment, you may need to cope with language differences. For example local “administrators” in dutch is “beheerders” and in portuguese it is “administradores”. Under the hood there is a common thing that can be used and that is the SID of that group which is universal and language independent. So, how to use that in PowerShell scripts?

First things first…

Defining the main function….

### FUNCTION: Test Credentials For Specific Admin Role
Function testAdminRole($adminRole) {
    # Determine Current User
    $currentUser = [Security.Principal.WindowsIdentity]::GetCurrent()
   
    Write-Host ""
    Write-Host "The Current User Is: ‘$($currentUser.Name)’…" -ForeGroundColor Yellow
    Write-Host ""
   
    # Check The Current User Is In The Specified Admin Role
    (New-Object Security.Principal.WindowsPrincipal $currentUser).IsInRole($adminRole)
}

Now to test for local admin credentials…

The local administrators group always has the SID “S-1-5-32-544”, no matter what it is called. Therefore based upon the (object)SID of the local administrators group we need to translate it into a a group name.

### Test For Local Admin Credentials
$localAdminSID = "S-1-5-32-544"
$localAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($localAdminSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsLocalAdmin = $null
$userIsLocalAdmin = testAdminRole $localAdminRoleName
If (!$userIsLocalAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Local Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$localAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
     Write-Host "Your User Account IS Running With Local Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$localAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 1: Testing For Local Admin – Failing

image

Figure 2: Testing For Local Admin – Succeeding

Now to test for domain admin credentials…

The domain administrators group is AD domain specific but always has the RID “512”, no matter what it is called. Therefore based upon the AD domain based (object)SID of the domain admins group we need to translate it into a a group name.

### Test For Domain Admin Credentials
$targetedDomainFQDN = "IAMTEC.NET"
$targetedDomain = Get-ADdomain $targetedDomainFQDN
$targetedDomainObjectSID = $targetedDomain.DomainSID.Value
$domainAdminRID = "512"
$domainAdminObjectSID = $targetedDomainObjectSID + "-" + $domainAdminRID
$domainAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($domainAdminObjectSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsDomainAdmin = $null
$userIsDomainAdmin = testAdminRole $domainAdminRoleName
If (!$userIsDomainAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Domain Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$domainAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
    Write-Host "Your User Account IS Running With Domain Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$domainAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 3: Testing For Domain Admin – Failing

image

Figure 4: Testing For Domain Admin – Succeeding

Now to test for enterprise admin credentials…

The enterprise administrators group is specific to the forest root AD domain of an AD forest but always has the RID “519”, no matter what it is called. Therefore based upon the forest root AD domain based (object)SID of the enterprise admins group we need to translate it into a a group name.

### Test For Enterprise Admin Credentials
$adForest = Get-ADForest
$targetedRootDomainFQDN = $adForest.RootDomain
$targetedRootDomain = Get-ADdomain $targetedRootDomainFQDN
$targetedRootDomainObjectSID = $targetedDomain.DomainSID.Value
$enterpriseAdminRID = "519"
$enterpriseAdminObjectSID = $targetedRootDomainObjectSID + "-" + $enterpriseAdminRID
$enterpriseAdminRoleName = (New-Object System.Security.Principal.SecurityIdentifier($enterpriseAdminObjectSID)).Translate([System.Security.Principal.NTAccount]).Value
$userIsEnterpriseAdmin = $null
$userIsEnterpriseAdmin = testAdminRole $enterpriseAdminRoleName
If (!$userIsEnterpriseAdmin) {
    Write-Host ""
    Write-Host "Your User Account IS NOT Running With Enterprise Administrator Equivalent Permissions!…" -ForeGroundColor Red
    Write-Host "The user account IS NOT a member of ‘$enterpriseAdminRoleName’!…" -ForeGroundColor Red
    Write-Host "Aborting Script…" -ForeGroundColor Red
    Write-Host ""
} Else {
    Write-Host ""
    Write-Host "Your User Account IS Running With Enterprise Administrator Equivalent Permissions!…" -ForeGroundColor Green
    Write-Host "The user account IS a member of ‘$enterpriseAdminRoleName’!…" -ForeGroundColor Green
    Write-Host "Continuing Script…" -ForeGroundColor Green
    Write-Host ""
}

image

Figure 5: Testing For Enterprise Admin – Failing

image

Figure 6: Testing For Enterprise Admin – Succeeding

Have fun!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in PowerShell | Leave a Comment »

(2019-02-14) Enabling Device Registration/Authentication In ADFSv4 Fails

Posted by Jorge on 2019-02-14


As mentioned in Configure Device Registration for Hybrid Windows Hello for Business device registration and authentication must be enabled in ADFS to support Azure AD Device Authentication on-premises against ADFS. It describes the steps on how to achieve this.

You start with:

Initialize-ADDeviceRegistration -ServiceAccountName <Service Account In ADFS> -DeviceLocation <FQDN AD Domain Storing Device Objects From AAD>

image

Figure 1: Initializing Device Registration In AD

This creates the required DRS objects in the configuration NC and in the domain NC specified to host the AAD devices written back to AD.

Looking in ADFS in the “Device Registration” node you will see the following, which is weird.

image

Figure 2: Device registration Overview Mentioning It Still Needs To Be Configured

Clicking on “Configure Device Registration” results in the following message. Just click “OK” to continue

image

Figure 3: Message After Clicking “Configure Device Registration”

Waiting until it finishes results in the exact same state as displayed in figure 2. Huh?

In PowerShell executing the following command:

Get-AdfsDeviceRegistration

…does not display the DN of the DRS objects that are in AD. It should specify a value for DrsObjectDN and DeviceObjectLocation, but it does not as you can see or even experience yourself. The event logs do not give you information of why not.

image

Figure 4: Empty Values For DrsObjectDN And DeviceObjectLocation

After some digging around, I found that in my ADFSv4 the EnrollmentServer endpoint was disabled and because of that it caused the device registration configuration to not succeed.

image

Figure 5: EnrollmentServer Endpoint Being Disabled

After enabling the EnrollmentServer endpoint through the GUI and restarting the ADFS service on every ADFS server in the ADFS farm (or using the PowerShell commands below)

Get-AdfsEndpoint /EnrollmentServer/

Enable-AdfsEndpoint /EnrollmentServer/

Set-AdfsEndpoint /EnrollmentServer/ -Proxy $True

Get-AdfsEndpoint /EnrollmentServer/

Restart-Service ADFSSRV # Execute On EVERY ADFS Server!

image

Figure 6: Enabling The EnrollmentServer Endpoint

Now you can see that there are values for DrsObjectDN and DeviceObjectLocation

Get-AdfsDeviceRegistration

image

Figure 7: Values For DrsObjectDN And DeviceObjectLocation

image

Figure 8: Device Registration And Device Authentication Now Being Enabled In ADFS

Have fun!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Device Registration | Leave a Comment »

(2019-02-13) Using Fiddler During Troubleshooting And Achieving SSO At The Same Time

Posted by Jorge on 2019-02-13


For those working with federation systems and applications, Fiddler is THE MUST HAVE TOOL, when troubleshooting or diagnosing stuff when it is broken or not working correctly.

By default Fiddler is not configured for SSO. Therefore when you access a site connected to, for example ADFS, you’ll see an authentication popup requesting for credentials as you can see below.

image

Figure 1: Authentication Popup When Using Fiddler Due To “Extended Protection” Feature In ADFS

Better yet, due to the Channel Binding Token feature (a.k.a. “Extended Protection”) of ADFS, in older version it was not even possible to achieve SSO without disabling CBT/EP first in ADFS. Doing so meant decreasing the security of your ADFS environment, just for troubleshooting. Also see: https://blogs.msdn.microsoft.com/openspecification/2013/03/26/ntlm-and-channel-binding-hash-aka-extended-protection-for-authentication/

In newer version it became possible to configure a rule that would make SSO possible. This is described in the following post: https://blogs.msdn.microsoft.com/fiddler/2011/09/04/fiddler-and-channel-binding-tokens-revisited/

In at least the latest version of Fiddler, it is now possible to enable SSO by just enabling the Fiddler option “Automatically Authenticate” which is available through the “Rules” menu. See below.

image

Figure 2: Achieving SSO By Enabling The “Automatically Authenticate” Option In The Rules Menu

Yes! Now easily solved so you do not got authentication prompts!

Have fun!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Tooling/Scripting | Leave a Comment »

(2019-02-08) Troubleshooting HTTPS/LDAPS

Posted by Jorge on 2019-02-08


My ADFS environment has an attribute store configured to an ADLDS and for that I used the “ldapattributestore” that still is available in the codeplex archives (https://archive.codeplex.com/?p=ldapattributestore). Because that ADLDS instance was running on a DC with ADDS, I configured the ADLDS instance to use port 5389 for LDAP and port 5636 for LDAPS. The “connection" string” for that LDAP Attribute Store was configured to use a secure connection (i.e. LDAPS) over port 5636. As I was checking functionality of my test environment I also tested this part by targeting the “Show My Claims” app (https://jorgequestforknowledge.wordpress.com/2015/07/04/displaying-the-issued-claims-in-a-security-token-on-screen/) that dives into that LDAP Attribute Store and displays specific claims on screen.

As I did not use my test environment for some time, several certs were expired and needed replacement. I opened the Local Machine certificate store and replaced every certificate that was expired or was going to expire soon with a new certificate using the exact same subject and SANs. After updating all certificates I started configuring and testing every single application using a certificate. So as you can imagine at some point in time I ended up with ADFS, the Show My Claims web site and with that the LDAPS attribute.

As an initial test I accessed the Show My Claims web site and due to the Issuance Transform Rules ADFS needed to dive into the ADLDS attribute store to source claims being displayed on screen. Unfortunately that failed. Looking at the ADFS Admin Event Log, ADFS was having issues accessing the Attribute Store. Those issues were related to the usage of LDAPS.

In that case I needed to start the basic testing of LDAPS through the good old LDP and see what was going on.

So after starting LDP and entered the FQDN of the ADLDS instance and its configured LDAPS port   

image

Figure 1: Starting LDP And Connecting To The ADLDS Instance Using The FQDN, The LDAPS Port

After clicking OK I was not surprised about the error “cannot open connection”. The more interesting question was “WHY?”

image

Figure 2: Error When Connecting To The ADLDS Instance

For this ADLDS instance I had a certificate with a subject and SAN that contained “IDSTORE.IAMTEC.NL”. I also permissioned the corresponding private key with the service account being used by the ADLDS instance. So far so good, but even with that it did not work. That’s when I decided to check all the requirements of a certificate to be used for LDAPS and used the following Microsoft article:

The certificate that I was using fulfilled all requirements and with that in mind it was time to enable debug logging for SCHANNEL when using HTTPS or LDAPS:

To make sure I was not missing any information, I configured the following for debug logging of SCHANNEL:

  • 0x0001 Log error messages
  • 0x0002 Log warnings
  • 0x0004 Log informational and success events

After enabling debug logging for SCHANNEL I tried it again with LDP and in the SYSTEM Event Log I saw the following error.   

image

Figure 3: Error When Accessing The Private Key

A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

I reconfirmed the certificate for IDSTORE.IAMTEC.NL had its private key configured for the service account in use by the ADLDS instance. It still did nit work

I also saw the following event in the SYSTEM Event Log

image

Figure 4: The Private Key Being Used By The ADLDS Instance

The TLS server credential’s private key has the following properties:

   CSP name: Microsoft RSA SChannel Cryptographic Provider
   CSP type: 12
   Key name: d40c17eadd0fb4c1e33541e54ebf55b1_c9c5687f-fc0b-4765-bc6d-2435ba59e1b2
   Key Type: key exchange
    Key Flags: 0x20

The attached data contains the certificate.

The event shown above mentioned the private key being used by the the ADLDS instance, but it still did not mention which certificate was being used. Switching to the details TAB, it told me more about the corresponding certificate that was being used. Going through the data I noticed it contained the SANs “*.IAMTEC.NET” and “*.IAMTEC.NL”. That was surprising to me as the certificate that envisioned for the ADLDS only contained “IDSTORE.IAMTEC.NL” as subject and as SAN.

image

Figure 5: The Certificate Data That Belong To The Private Key

After seeing this I remembered the following listed in the first MSFT article:

Multiple SSL certificates

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate

What I never realized was that my wildcard certificate was going to be used first before even considering the usage of the certificate that contained the more specific subject and SAN.

As displayed below I permissioned the private key that belonged to the wildcard certificate ….

image

Figure 6: Permissioning The Private Key Of The Wildcard Certificate

Retried my test with LDP as shown below….

image

Figure 7: Retrying The LDAPS Test With DP

….and now it worked. You can see at the top it is connecting securely through LDAPS and that it is using a cipher strength of 256 bits

After this I check the LDAP Attribute Store configuration to make sure everything was configured correctly. And it was. Retrying accessing the Show My Claims site I was able to the claims that were sourced from the ADLDS instance

Check!

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Active Directory Lightweight Directory Services (ADLDS), Attribute Store, Certificates, Claim Types, LDAPS, LDAPS, LDP | Leave a Comment »

(2019-02-07) People Picker Error In Sharepoint 2013

Posted by Jorge on 2019-02-07


From time to time I fully update my test/demo environment to make sure all the installed stuff uses the latest available features for those versions. And yes, I’m still running some old versions because I need the basic functionality for some things to work and do not need the latest and greatest. Because I’m still running everything on a server on-premises, yes those people still exist, I need to careful will the latest and greatest apps behaving as resource hogs. And that’s why I’m still running Sharepoint Foundation 2013. At the same time while updating I some times also try out stuff just to see if things are still working. This blog is basically more about archiving this piece of information from my brain the next time it happens so I do not forget it.

This time, even as a Site Collection administrator, I was not able to navigate to the site or assign permissions to some AD group or user.

In the first case, I saw the error “Sorry, You Don’t Have Access To This Page”. For me that was quite surprising as by default Site Collection admin have Full Control.

image this

Figure 1: Error “Sorry, You Don’t Have Access To This Page”

Browsing to the settings page to assign permissions, using a direct URL (“https://<FQDN>:<PORT>/_layouts/15/settings.aspx”)as navigation was not possible. While trying to assign permissions to a group, the group could not be resolved and it showed the error “Sorry, We’re Having Trouble Reaching The Server”

image

Figure 2: Error “Sorry, We’re Having Trouble Reaching The Server” While Resolving A Security Principal

I googled around and noticed I was not the only one having this issue. After trying a number of solutions, the only solution that really worked for me was extending the web application and when done unextending it again.

To extend a web application:

  • On the Sharepoint Server start a browser and navigate to the Central Administration site
  • On the Central Administration site in the Application Management section  click “Manage Web Applications”
  • Select the web application that is not working due to the errors above and in the ribbon click “Extend”
  • Make sure the option “Create A New IIS Web Site” is selected
  • Check all the other settings and see if those do not conflict with any other web application on the same box, and when OK click “OK” at the bottom
  • After letting the system finish the extension of the web application, try to assign permissions again

…and if correct you should now be able to resolve security principals from AD.

image

Figure 3: Resolving A Security Principal From AD Now Does Work

After confirming, it is working again, you can UNextend the web application again.

To UNextend a web application:

  • On the Sharepoint Server start a browser and navigate to the Central Administration site
  • On the Central Administration site in the Application Management section  click “Manage Web Applications”
  • Select the web application that was previously extended for which you want to delete the extension
  • On the ribbon, just below the “Extend” button click on the tiny arrow and select “Remove Sharepoint from IIS Web Site”
  • Select the correct extension to delete
  • Make sure to delete the IIS Web Site too

You should be good now. At least I was! Smile

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Sharepoint Server | Leave a Comment »

(2019-01-03) Some Phones Are Not That Good With Face Recognition

Posted by Jorge on 2019-01-03


Are you using face recognition to unlock your mobile phone?

And is that mobile phone on the following list?

It appears all the mobile phones on the list can be unlocked by using a picture instead of your face.

To be sure nobody access your personal data that easy, preferably and if possible use finger or a code to unlock the mobile phone

All the phones on the list titled “Toestellen ontgrendeld met een foto” can be easily unlocked with a photo of your face

All the phones on the list titled “Toestellen ontgrendeld met een foto, maar met betere beveiliging” can also be easily unlocked with a photo of your face but also provide more secure settings for face recognition

All the phones on the list titled “Toestellen die niet met een foto zijn te ontgrendelen” appear to be secure and face recognition is not fooled by a photo of your face.

From the dutch consumers authority:

https://www.consumentenbond.nl/veilig-internetten/gezichtsherkenning-te-hacken

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided “AS IS” with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-

########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################

————————————————————————————————————————————————————-

Posted in Day-To-Day Stuff, Mobile Devices, Security | Leave a Comment »

(2019-01-01) Happy New Year 2019!

Posted by Jorge on 2019-01-01


A happy new year 2019 to everyone!. Enjoy, have fun and make the best of it!

Related image

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
####################
http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

Posted in Day-To-Day Stuff | Leave a Comment »

 
%d bloggers like this: