Decentralized Identity (DID) - Verifiable Credential - Microsoft Verified ID

Traditional IDs are issued/owned by IdPs. From user's perspective, these IDs among different IdPs can be inconsistent, hard to maintain, and there is no guarantee of privacy, control, etc.

Decentralized ID lets a user owns his/her ID. Any other entity can then add claims to DID. For example, an employer can add employment claim to its employees' DIDs. Therefore, traditional IdPs no longer own IDs, they either become irrelevant to a person (if they can't add/verify claims about the said person), or they transform themselves to be claim issuer (if they know something about the holder) /verifiers (in this case, the old IdP is just a consuming party of DID model).  

"Claims" here is called "Verifiable Credentials"(VCs) in DID context. It's verifiable because it's digitally signed. Entities that assign/sign VCs are called Issuer.

DID creation, change, as well as claim history, are stored in a public, decentralized network. It can be tracked and verified without a centralized IdP. Such network is called Trust Systems. Examples include ION (Identity Overley Network) and DID:web. Trust System can be built on top of existing blockchain network such as Bitcoin.

For the model to work, there are implicit trusts listed below:

• Issuer trusts holder
• Verifier trusts issuer
• Holder trusts verifier

Set up a hybrid Azure AD lab

 General steps

1. Set up an on-premise AD with forest name johnfoo.tk
2. get a free domain from freenom (johnfoo.tk)
3. In Freenom, configure to use your own DNS server, pointing to on-prem DC IP
4. set up Azure AD 
5. create an Azure account for AAD Connect, make it Global Admin
6. create an AD service account for AD, give it DC Sync permission (or let AD Connect create for you)
7. Add and verify Custom Domain in AAD. Create the TXT record on your AD DNS. The "@" -named record required by Azure is equivalent of "(same as parent)" record in Windows DNS. Just leave the record name blank when create the TXT record.
8. Install AD Connect, enable
1. PHA (recommended, for auth fault tolerance, or PTA). Of course, use federation is also possible depending on if you are using ADFS right now on prem
2. Enable Seamless SSO (for on prem users SSO into Azure)
3. Be careful what attribute to use for join rule (?). UPN is a good candidate. Unless on prem users are already having email address, using mail for linkage will not work

Manually join Windows clients into Azure AD

1. Enable join/register option for regular users: AAD|Devices|Device Settings|Users may join devices to Azure AD
2. On Win client, Accounts, connect to work, then select "join this device to Azure AD", follow on screen instructions 
3. use "AzureAD\azureUPN" to log into the newly joined machine (e.g. AzureAD\jlan@johnfoo.tk)

Manually register Windows clients into Azure AD

1. Same steps as above, but in step 2, do not select "join this device to AZure AD", instead, just click on "next" button 

Create a B2C Tenant

1. Run "az provider register --namespace Microsoft.AzureActiveDirectory"
2. Follow on screen instruction

Grant Admin access to an Azure-joined machine

1. Tenant wide permission
1. Azure AD has a "Device administrators" role that is used for this purpose
2. Go to Devices | Device Settings | Manage Addtional local administrators on all Azure AD Joined devices | +assignment
2. Individual machine
1. Locally on the machine, using Account Settings to elivate a user
2. "net localgroup administrators /add "Contoso\username" for adding on-prem user
3. "net localgroup administrators /add "AzureAD\UserUpn" for adding Azure user
4. use MDM solution

Enabled Hybrid AD join

1. Run ADC, select Configure | additional tasks | Configure device options
2. Follow on screen instruction

Create a split-DNS for AD forest with same AD-domain name and DNS-domain name

 This is useful for a lab environment where you have an AD forest uses same domain name AD-wise and DNS-wise

• Set up
• domain name: foo.bar
• internal subnet: 192.168.0.0/24
• Commands
• Add-DnsServerClientSubnet -Name "loopback" -IPv4Subnet 127.0.0.0/24
  Note: don't forget to add loopback as internal subnet 
• Add-DnsServerClientSubnet -Name "internal" -IPv4Subnet 192.168.0.0/24
• Add-DnsServerZoneScope -ZoneName "foo.bar" -Name "internet"
• Add-DnsServerResourceRecord -ZoneName "foo.bar" -A -Name "@" -IPv4Address "yourPublicIP" -ZoneScope "internet"
• Repeat above to add other A records that needs a public internet presence
• Add-DnsServerResourceRecord -ZoneName "johnfoo.tk" -name "@" -NameServer "yourPublicIP" -NS -ZoneScope "internet" (Optional, your DNS provider already knows how to find your name server)
• Add-DnsServerQueryResolutionPolicy -Name "NonInternalPolicy" -Action ALLOW -ClientSubnet "ne,Internal,loopback" -ZoneScope "Internet,1" -ZoneName "foo.bar"
• Add-DnsServerResourceRecord -ZoneName "johnbook.ga" -name "@" -TXT -DescriptiveText "MS=ms35639551" -ZoneScope "internet"