ADFS 3.0 Service does not start after Reboot

[StephenHardy]

Hi All,

 

We are running 2 x Server 2012 R2 Servers as an ADFS Farm (Server 2008R2 Domain however) for Office 365. Everything installs fine and we can pass-through authenticate through the Web Application Proxy NLB we have setup.

 

However, when we reboot either of the ADFS servers the ADFS Service never starts, if you try to manually start the service you receive a 1297 error - looks like User Rights Assignment for the Domain Admin account running the service.

 

Does anyone know what rights this needs - cant seem to find anything online - I've been trawling all day...

 

Thanks

 

Stephen

[free780]

Does it need to be

Domain Admin account running the service

?

[StephenHardy]

Tried with a local service account, no dice.... I cant use a GMSA as its Server 2012R2 and the domain is Server 2008R2...

 

At present, every time I reboot either ADFS server I have to remove, re-add and re-setup the Farm.

[free780]

Is event viewer unhelpful?

[EduTech]

Hi Stephen,

 

What is the exact error message you get, is it pretty much the following "A privilege that the service requires to function properly does not exist in the service account configuration."

 

The Server 2012 'adfssrv' service requires the following Required Privileges:

 

Constraint/Value

SE_AUDIT_NAME

TEXT("SeAuditPrivilege")

 

In English... :-)

Required to generate audit-log entries. Give this privilege to secure servers.

 

User Right: Generate security audits.

 

Can you please launch gpedit.msc on the AD FS Server and Check under User Rights Assignment if the account that you are using for the Service Account is added to that setting.

 

let me know how you get on,

 

Thanks.

James.

Edited June 17, 2014 by EduTech

[StephenHardy]

James

 

That's the one - thanks

 

Stephen

[EduTech]

So, Did that fix your issue? or... :-)

[StephenHardy]

Hi James,

 

Yes indeed - would you believe I was actually on the phone for a while to one of your colleagues at the time. 60 odd minutes of testing and it was back to my original assumption of User Rights Assignment, which you answered

 

Cheers Buddy, now onto getting accounts to auto provision based on group membership...

 

Stephen

[EduTech]

Hi Stephen,

 

Good to hear I am pleased to hear that it is now resolved.

 

Thanks,

James.

[StephenHardy]

James,

 

Got an issue with the secondary ADFS server, which, if enabled in the NLB and accessed for authentication, causes authentication to fail. I think this is due to the ADFS having a stuck record much like here http://community.office365.com/en-us/f/613/t/59106.aspx.

 

Any ideas how to remove the record for the secondary ADFS server to get this working again?

 

cheers

 

Stephen

[StephenHardy]

Forgot to add, the farm name and server names have been used many times before...

[StephenHardy]

Sorted it. It was because I was importing the ADFS settings from an old farm that may of been corrupted. i.e. The Farm was created which created a new cert store, the settings were imported which set the farm to use a no longer existing store:

 

So I followed this:

 

To manually delete this container in Active Directory, follow these steps:

 

1. Before you remove AD FS 3.0 from the last federation server in the farm, run the following PowerShell commands on the AD FS 3.0 Primary Federation Server to determine the location of the certificate sharing container in Active Directory:

 

Get-AdfsProperties

 

2. Note the CertificateSharingContainer property in the output from the previous step.

3. Log on to a server where the ADSIEdit tool (ADSIEdit.msc) is installed.

4. Click Start, click Run, type ADSIEdit.msc, and then press ENTER.

5. In the ADSIEdit tool, connect to the Default naming context by following these steps:

a. Right-click ADSI Edit, and then click Connect to.

b. Under Connection Point, click Select a well-known Naming Context, and then select Default naming context.

c. Click OK.

 

6. Expand the following node:

 

Default naming context, YOUR SITE ID, CN=Program Data, CN=Microsoft, CN=ADFS

Note Under CN=ADFS, you see a container named CN={GUID} for each AD FS 3.0 farm that you have deployed, where {GUID} matches the CertificateSharingContainer property that you captured by using the Get-AdfsProperties PowerShell command in step 1.

 

7. Right-click the appropriate {GUID} container, and then select Delete.

 

 

 

Then I re-installed the ADFS Role, setup in the usual way, converted the Domain to Managed using this PS script:

 

$cred=Get-Credential

Connect-MsolService -Credential $cred

Set-MSOLDomainAuthentication -Authentication Managed -DomainName my-domain.com

 

Then converted back to federated using this PS script::

 

$cred=Get-Credential

Connect-MsolService -Credential $cred

Convert-MsolDomainToFederated -DomainName my-domain.com

 

 

WAP now connects to the ADFS NLB and all is rosey… now onto auto-provisioning students and staff into their respective plans – any suggestions here?

 

Thanks

 

Stephen