none
Need some help with ADFS Claims Rules for Windows 10 Device Registration

    Question

  • Hi everyone,

    So, I'm back at this little roadblock again, and hope to get some more information regarding the ADFS Relying Party Trust Claims Rules required to enable Azure AD Windows 10 Automatic Device Registration work.

    To begin with, here's the latest guide I found: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

    So, what's confusing me? Well let's see:

    1. In Step 2 of the link above (Setup issuance of claims), we have a note regarding the enabling of Windows Transport rules. Weirdly, in my current environment, I have both "adfs/services/trust/13/windowstransport" and "adfs/services/trust/2005/windowstransport" enabled, and enabled for proxy. I'm not sure how both got enabled, but our current ADFS configuration and Office 365 Identity Platform rules for users, are working a treat. Is this something I need to remedy, or can both stay enabled?

    2. Still in Step 2, let's take a look at the PowerShell for the section "Issue issuerID for computer when multiple verified domain names in Azure AD". This all looks pretty straight-forward, except for the "http://<verified-domain-name>/adfs/services/trust/" on the second-last line. In the notes below the rule, it says that this "is a placeholder you need to replace with one of your verified domain names in Azure AD". So... I guess I just replace this with one of the verified domain names I see when running "Get-MsolDomain"?

      Furthermore, should that URL actually work in a web browser for testing? Testing a URL such as (not using real domain names, obviously) "http://domain.name/adfs/services/trust/" results in a failure, so I assume that's not what this actually means. In that case, our external ADFS is on "https://fs.domain.name/adfs/", and our verified domains are "domain.name" and "child.domain.name" (parent/child domain in a single forest). So, would this just be our "domain.name"? or would I need to use "fs.domain.name" as this value?

    3. Again, in the same rule as above, we're told "$<domain> is the AD FS service URL". I find that rather ambiguous. Is that telling me, or asking me to change something? More annoyingly, "$<domain>" doesn't even appear to exist in the code supplied. I only see "${domain}", and that's part of the RegEx, right?

    4. Now let's go down a bit further, to the "Helper script to create the AD FS issuance transform rules" section. Now we're really getting confusing.

      a) This is a code block merging all the individual rules from above it, including those I questioned in the previous couple of points. Now, just from a consistency point, I would have liked some bullet points in the "Remarks" section that again stated the requirement to change the "<verified-domain-name>", and whatever (if anything) was required for the "$<domain>" thing.

      b) At the top of the script, we're asked to replace "example.com" in the "$oneOfVerifiedDomainNames" variable, however the code doesn't actually reference this at all. I assume this was meant to be in place of the "<verified-domain-name>" string in the last rule.

      c) In the "Remarks" section, we're told that if we "have already issued an ImmutableID claim for user accounts, set the value of $oneOfVerifiedDomainNames in the script to $true". Umm, shouldn't that be setting the "$immutableIDAlreadyIssuedforUsers" variable to "$true"?

    Annoyingly, even though I can clearly read what this script is meant to be doing, I have no idea how to make it work. Why are Claims Rules so strange? More importantly, why can't I get these to work? This is my fourth go at this... and I either end up with rules that don't work, or rules that break my ADFS for our existing, working, Office 365 environment.

    Help appreciated.

    Murray


    • Edited by HSICT Wednesday, April 19, 2017 8:40 AM
    Wednesday, April 19, 2017 8:40 AM

All replies

  • Hi Murray, I am Jairo Cadena from the Azure Active Directory team at Microsoft.

    About the 2005 vs. 13 WS-trust end-points as long as one is enabled device registration and authentication should work.

    About the <verified-domain-name> tag, yes that should be replaced with one of the values returned by Get-MsolDomain cmdlet. Also the constructed value is an URI and not a URL. The URI is used by Azure AD to identify the tenant. As it is not a URL you won't see this navigating to a specific location in a browser.

    Also thanks for the feedback on the script. We are in the process of fixing the two issues your point out:

    1. $oneOfVerifiedDomainNames not being used in the script. The script refers to <verified-domain-name> instead of the variable that can be set at the beginning of the script.
    2. In the remarks the reference to $oneOfVerifiedDomainNames to determine whether the Immutable ID claim should be sent or not. This will change to $immutableIDAlreadyIssuedforUsers as you mention.

    We hope to have these changes live within the next couple of days.

    You need to make sure in the end that the rules are described in the document are created (and not duplicated for example). You can also take a look at this article to check status on the device being registered: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-device-registration-troubleshoot-windows.

    Jairo [MSFT]


    Friday, April 21, 2017 8:55 PM
  • I understand your frustration with this. I just spent about 20 hours troubleshooting problems with automatic AAD joining. I am running the latest version of AD Connect, and am running an ADFS farm on Server 2016. I did NOT let AD Connect configure my ADFS servers.

    It does look like they have corrected that script you were referring to. Now that i practically understand this whole process inside and out, I can say that the script actually does work and adds the correct claims rules.

    However, what is misleading is how to configure the couple of variables in the script. So, I thought I would clarify based on my learning, hopefully it will save somebody some time.

    • $MultipleVerifiedDomainNames: The description and name is both WRONG and MISLEADING. Set this to $TRUE only if you have MULTIPLE FEDERATED DOMAINS in your Office 365 tenant.
    • $immutableIDAlreadyIssuedforUsers: If the Immutable ID (Source Anchor) for your AD Connect synchronization does NOT use objectGUID then set this to $TRUE.
    • $oneOfVerifiedDomainNames: If you set $MultipleVerifiedDomainNames to $true, then set this to the Office 365 verified domain name that you want your devices to register to.

    Do not change any other components of the script, and make sure you only run it once. If you need to run it again, you need to manually remove the added claims issuance rules from the RP trust or they will be duplicated.

    Another very helpful thing to know when it comes to troubleshooting on Windows 10, use DSREGCMD. It has to run as SYSTEM so you'll need something like PSEXEC.

    psexec -i -s cmd.exe
    dsregcmd /debug

    This will force an immediate registration to Azure, and report detailed information about the failure.

    During my testing, Windows 7 worked fine, but Windows 10 would not AD join. If the ImmutableID is the problem you'll see the error is: AADSTS90019: No tenant-identifying information found in either the request or implied by any provided credentials.

    If, you included a verified domain when you shouldn't have or it's wrong you'll see: AADSTS50107: Requested federation realm object '<your specified domain>' does not exist.


    Tuesday, July 18, 2017 6:32 PM