To create a new Issuance Transform Rule on the relying party trust. Follow these steps:

Choose Add Rule. 

Use the Send LDAP Attributes as Claims template

Name the rule and choose the Active Directory attribute store.

Next, type the custom attribute name I the Ldap Attribute dropdown exactly as it appears in ADSI Edit or your favorite ldap browser of choice. Hit enter.

You will notice that now if you choose the dropdown, the custom attribute is saved towards the bottom for future use.

You can now map that attribute to any of the claim types built in to ADFS and select Finish.

That how to map your custom Active Directory attribute in an ADFS claims rule. Deceptively easy.  Hope this helps.

“The SSL certificate does not contain all UPN suffix values that exist in the enterprise….” 
  

Assuming you have internet access, the link in the event actually takes you here, which is perfect – https://technet.microsoft.com/library/dn614658.aspx

The thing is, depending on how far you’ve gotten with configuring Device Registration – if at all – you may be wondering how much of this is necessary?  What if I just edit the certificate?  And what UPN’s need to be defined anyway? The short answer is that no matter how far you have or haven’t gotten configuring DRS, you’ll need to walk the full Technet article and hopefully I can fill in the gaps to help you accomplish just that.

The first section of the TechNet discusses DNS.  You’ll already have an A record for the ADFS server. There will also need to be enterpriseregistration CNAME records for each domain that needs access to workplace join.  Yes, this means child domains too so don’t think just because you have enterpriseregistration.contoso.com that you can forego creating enterpriseregistration.child.contoso.com.  The record will need to exist in each domain’s DNS zone.

The second section of the Technet covers certificate issuance; specifically around the ADFS service communications certificate.  In addition to the aforementioned Cname records, we also need SAN entries for each enterpriseregistration.domain.com instance. 

Once the certificate request is completed with the correct common name and SAN entries, a new certificate is issued which  you bind to ADFS in the next step in the Technet; namely the “Set-AdfsSslCertificate -Thumbprint thumbprint” command.  I recommend doing the update using this method versus the GUI as I’ve seen some funny things happen when going the GUI route.  A restart of the ADFS service at this point is a prudent measure as well. 

Pretty straightforward so far, but wait a minute –  before I go reissuing certificates and creating all of these DNS records how many domains are going to need this to get rid of the 415?  The answer lies in this statement regarding Set-AdfsDeviceRegistrationUpnSuffix &Get-AdfsDeviceRegistrationUpnSuffix

“This command will detect the UPNs associated with Active Directory forests and domains and configure AD FS to listen.”

If DRS is already running then you should be able to run Get-AdfsDeviceRegistrationUpnSuffix from a Powershell prompt to find out. If, however, you have yet to dip even a solitary toe into the DRS pool using expert advice like this blog - https://blogs.technet.com/b/amitd/archive/2014/05/07/configure-adfs-and-device-registration-service-in-windows-2012-r2.aspx to run the commands to initialize & enable DRS here’s a good rule of thumb: if it’s listed as a trust in Active Directory Domains & Trusts you should consider whether you’ll want those users to workplace join.  To get rid of the 415, you’ll need to define a SAN for each domain in the certificate.  Now, if you’re at this  stage of the game and haven’t initialized or enabled DRS you’ll want to consult the aforementioned blog to get that done before worrying about the finer points of UPN suffix binding. 

Getting back to the action, we left off at updating the certificate.  This alone will not make our 415 go away nor will it allow our friends in other forests or domains to workplace join using our STS.  We next have to kick ADFS upside the head with a

Set-AdfsDeviceRegistrationUpnSuffix

This, ironically, will also give you the same message from the 415 event.  Stand fast, undaunted in your quest for DRS perfection.  Success is just around the bend. Continuing with the Technet process we follow this by running

Get-AdfsDeviceRegistrationUpnSuffix

For each UPN, the “IsSetAsSSLBinding” should now be equal to True.  If it doesn’t happen right away, re-run the Get- command another time or two and see if it updates.  Even in my lab I had to give it a bit of time.  Here’s how it looks.

At that point, if the certificate is updated and the configuration refreshed with the Set- command, you’ve likely seen your last 415 for a while.

As the final step of the Technet, make sure to go out there and update the WAPs with an “Update-WebApplicationProxyDeviceRegistration”  Congratulations, you’ve made it to the end. 

A natural question might be “what if I don’t want to give workplace join rights to every trusted & trusting domain?”  Completely reasonable query.  Let’s go back to the beginning by remembering that the 415 is a Warning, which will result in neither loss of limb nor your high school yearbook picture being posted to social media if no action is taken.  It’s just Microsoft’s way of making you aware of a certain condition.  From a security standpoint, you may not actually be interested in granting workplace join permissions to organizations that don’t need it, which makes sense.  In that case, the 415 is no big surprise.  That said, if you want to know what it means and how to make it go away, follow the Technet and hopefully this additional advice will see you through.