locked
ADFS WID failure Server 2016 TP5 RRS feed

  • Question

  • Hey everyone.

    I'm looking at deploying Server 2016, particularity (ADFS + WAP). I began my stuff by building an entire test environment of my production which includes 3 DC's (Forest level 2008 R2, 2 2008 R2 DC's and one Sever 2012 DC). 

    Following Pages I've Read:

    AD FS PrerEqs

    Software: I installed AD FS Role on the 2016 TP5 as its own Role after adding the server as a member server to my domain.

    Certificate requirements: I have my own PKI and use it to make my own certificates. In this case I followed this guide, but it seems in the Post Deployment steps of AD FS it complains stating certauth.server.domain.com is not blah blah part of the SAN. I looked up every page I could find on Certificate requirements of AD FS, and not one mentions the SAN name as a requirement; not this one, or this one (Which is by far the best and most indepth blog I've seen about Certs around AD FS)

    Question #1 Revolves around this. If I do need this SAN in my Cert where is the details required for me to provide this in my cert (I easily can and know how to, but my question is why is it required and why is it not mentioned anywhere in these tuts?

    Next up! Under the Post AD FS wizard it asked me to create of specify a service account. I've recently gotten well caught up on MSA's, what they are, and how they are used and found a cheaveat that doesn't seem to be discussed else where. And that is the fact I create a MSA on my DC's, replicate it, install AD module for PS on said server, install the MSA, now when I go to specify it in the AD FS wizard it finds the MSA when I specify it, however the Next button is greyed out until I enter something in the password field... MSA require that the password field is blank! Did anyone in QA not catch this?!?! *UPDATE* if you create the MSA using the wizard it works, and even lets you click next when you pick this wizard created account and doesn't specify a password field and enables the Next button. However if you pick a manually created MSA it won't work.

    Next! And finally the whole point of this question/post.

    I have to specify a SQL DB for AD FS, since I'm running a test enviro I felt like keeping it simple and just use WID as its an option in the wizard. It will attempt to configure AD FS. Complain about the Certificate not having certauth.server.domain.com in the SAN then simply cry with an Error: "Cannot start the service MSSQL$MICROSOFT##WID on computer '.'.

    What am I doing wrong? Note these test systems have no internet connect. 

    Monday, May 30, 2016 6:55 PM

Answers

  • As for the base of this question; Answer is this

    However the Cert SAN question still remains, *UPDATE*

    I couldn't find any other AD FS deployment blog to fully cover the hostname binding for cert auth; However I did find this helpful MS Post.

    as well as the managed service account based question. *UPDATE*

    I was playing around in my lab and when I went to try and figure out which Computer Target a MSA was assigned to by running Get-ADServiceAccounts -Filter "samaccountname -like '*'" I was able to discover that the AD FS wizard creates a gMSA and not a standard MSA. At this point I'm going to assume AD FS wizard does this for deploying multiple AD FS servers while reducing the required amounts of MSAs (Plus not having to store multiple different password per MSA)

    That said, It still seems a bug that when you specify your own account under the AD FS wizard on which account to have the service run under and it asks for a password when you select a self created MSA. Just my feedback.


    • Edited by Zewwy Tuesday, May 31, 2016 6:54 PM
    • Marked as answer by Zewwy Tuesday, May 31, 2016 6:54 PM
    Monday, May 30, 2016 7:22 PM