Hey everyone,

I'm 17 and currently in Year 11, and I've been thinking a lot about what I want to do after school.

My long-term goal is to become a psychologist, so I know I'll need to go to uni. But lately I've also been considering doing an ADF Gap Year.

Last year I did a week of work experience at HMAS Cerberus. I only applied because I thought it would be a cool experience and wasn't seriously considering joining the ADF at all. But I ended up really enjoying it. Everyone was welcoming, I liked the environment, and it completely changed how I viewed the military.

The only thing is, I'm not a very confident swimmer, so I'm not sure if the Navy would be the best fit. Because of that, I've also started looking into the Air Force Gap Year instead.

What I'm worried about is doing a gap year, not enjoying it as much as I expect, and then feeling like I've delayed becoming a psychologist by a whole year for nothing. Psychology already takes quite a while to qualify in, so I keep wondering if I should just go straight to uni instead.

Has anyone been in a similar position? Did you take a gap year before starting a long degree? Do you regret it, or was it worth it? And if anyone has done an ADF Gap Year (especially in the Navy or Air Force), I'd love to hear what your experience was like and whether you think it was worth taking that extra year before uni.

Someone said I should post this issue here. Correct me where I am wrong!

I accidently came across this when I typed my url into the search bar instead of the address bar. This only happens if you click the link from Google and not when you type it in manually.

When this URL is opened (for example from a Google search), Microsoft begins a WS-Federation authentication flow using a request URL that includes parameters such as:

wa=wsignin1.0, wtrealm=urn:federation:MicrosoftOnline, and wctx=...

These parameters are part of the WS-Federation sign-in request context used by Microsoft to manage authentication state and routing.

This request is then evaluated by Microsoft’s Home Realm Discovery (HRD) system, which determines whether the sign-in should proceed through Microsoft’s cloud login system or be redirected to an external identity provider (such as an ADFS federation endpoint).

While testing, instead of first showing the standard Microsoft login interface, the flow immediately redirects to external ADFS endpoints such as https://fs.det.nsw.edu.au/adfs/ls/ or https://fed.unisa.edu.au/adfs/ls/. This indicates that HRD is selecting an external identity provider based on the perceived authentication context in the request. (Cached browser also adds my admin username to their login field)

Under normal conditions for a cloud-only login context, the expected behavior is that the user is first presented with the Microsoft sign-in page before any federation routing decision occurs. This does not happen.

Google redirects to the AU gov DoE.

Bing fails redirect on mid-authentication via SAML/WS-Fed.

Yahoo fails on mid-authentication via SAML/WS-FED.

Brave search takes me to the correct page oddly enough and doesn't redirect me.

I have no fucking clue what is going on at this point so I'm sharing my findings.

Multiple users verified the link results.

Why didn't I do this earlier!

The last 2 years of updating Service & Token SSLs have been mightmare, minefields of hope & prayer each time. Extensive step-by-step documentation of the procedure from one year doesn't work the next! A real dread for 2-3 months as the anneversary approaches and SSL lifespans shrink.

It's been on my to-do list for at least the last 6 months. Finally got the 2 month reminder to auto-renew the SSL cert and decided to actually have a go at what appeared to be a simple process (I'm rightly wary of 'simple' microsoft procedures and was in 2 minds about outsourcing the work) to move to Azure AD connect (or what ever they've rebranded it to this week).

So put some effort in on Monday, created the test group and ran!

...so far 3 of 5 domains de-federated without a hitch. Should have it all wrapped up by the end of next week. Then de-comissioning the following week.

What a relief.

Hi Everyone, wondering if anyone preparing for ADF careers officer roles, specialist entry. Could you please share any preparation tips and a practice platform?

I am creating a connector on a CMS for Dynamics 365 Sales (on-premise). My current setup is as below:

• My CRM server Domain is example.com
• I already have the authentication in place via ADFS to access this CRM.
• Then, I have created an application group to expose the web APIs and use them with the access token. But when I add the resource Identifier as example.com for web APIs, I am getting the "RPT should be unique" error.
• I found a solution to use example.com/example or example.com/web as a resource identifier.
• I did that and got the access token, but when I am trying to use this token, I am getting the error - "Unauthorized to access this resource." because for the token I fetched, the resource is example.com/example or example.com/web, but not example.com

Does anyone have a solution for this, or could help me to set it up asap?

I have an ADFS setup with two nodes (both Windows 2019).
There was an issue accessing the management console that is usually bypassed by restarting the service, and I've got notified that ADFS service is not restarting on the secondary node.

Starting the service throws an 1064 error, and this leads to a couple of 381 errors in the ADFS Admin event log regarding expired certificates.

Get-AdfsSSLCertificate returns the correct and valid communication certificate, that is also in the machine store.

I cannot run Get-AdfsCertificate as the service is not running.

I've managed to start a command prompt with the ADFS service account (GMSA) and checked the following:

• opened the WID with SMSS and retrieved the settingsdata from [AdfsConfigurationV4].[IdentityServerPolicy].[ServiceSettings]
  • This data had some thumbprints for Encryption and Signing certificate that turned out to be the correct thumbprints for the current (and valid) self-signed encryption and signing certificates of the primary ADFS node.
• opened the mmc certificates console for the service accounts certificate store only to find four expired certificates (2 for each encryption and signing)
  
  • The thumbprints here matched the thumbprints in the 381 errors in the ADFS event log
• I can't export the certificates from the primary node with their private keys to reimport onto the secondary node

I have no idea how to get the secondary node up and running again, and where does it take the thumbprints of the expired certificates from as they are apparently not in the WID database

Hello everyone!

I am trying to integrate SSO with ADFS server. When approaching the login page, it is popping the “Authorization required” window. When on Chrome, typing username and password works, redirect to the application. On Edge is consistently show the pop-up. klist tickets shows a ticket for the ADFS service on the client. I applied GPOs to make the URL in trust list, HTTP authentication and Kerberos delegation for chrome. I want to make seamless login, as the user is already authorized and authenticated.

What am I doing wrong? Why it keep on insisting to put username and password?

What I’ve done so far:

I deployed an ADFS (Server 2022) with Service account, certificate which contains certauth, VIP and servers in the farm, Service account which I manually set the ADFS SPN (HTTP/) on, dns records. I set WIA with forms, set the WIA User Agents to include Chrome and Mozilla, and set the relying trust party. Configured the SSO on application side to match the outgoing claims. When typing username password on chrome is redirecting, but I want a seamless login, so the user won’t have to type his username and password when already on domain and authenticated. Tried to set the ExtendedProtectionTokenCheck to None.

Best regards!

ADFS running on Microsoft Windows Server 2019 Datacenter.

Cert was added for Service Communication Cert in ADFS cert store in the ADFS GUI. It sees the new cert there.

Cert also added in Local Store with mmc.exe > Certificates.

Service account was added to the private key with mmc.exe > certificates.

Service was restarted after adding.

Primary key is visible when using digicert certutil and also mmc.exe > certs to check certs.

Server has been rebooted a few times.

I have Powershell ISE running as admin.

Set-AdfsSslCertificate -Thumbprint <thumbprint> fails.

The cert's thumbprint is shown when I do "dir cert:\LocalMachine\My"

Commands to clean bindings using netsh http delete sslcert did not work and returned an error: The parameter is incorrect.

Command netsh http delete sslcert hostnameport=localhost:443 did work.

I'm at a loss. Thankfully this is just test and I have a snapshot, but I need to do prod adfs in a few days and I don't want to go through this on prod.

Long story short.. i have a working ADFS farm.. it was consisting of 4 servers total.

2 internal

2 proxy

These were all 2016 servers, so my first task was adding two new 2022 servers to the internal farm, and after some time remove the two 2016 internal servers.. That was done, so now my internal farm consists of the two 2022 servers internally and two 2016 Proxy servers..

Now I need to do the same with the Proxy Farm..

I was able to find what I needed to get the internal farm upgraded without issue.. but finding very little information about the Proxy side..

Has anyone added and eventually removed servers from an existing ADFS Proxy Farm.. Is there anything I need to be aware of? Does anyone have any documentation other than the AI results I have been finding?

Hi all,

Our organization is a large enterprise that has been heavily invested in Active Directory Federation Services (ADFS) for years. We're now considering initiating a project to review and potentially trial more modern authentication mechanisms, but the scope feels daunting given our deep integration.

Our Current Situation:

• Extensive ADFS deployment with numerous integrated applications
• Complex on-premises infrastructure dependencies
• Significant investment in existing ADFS customizations and configurations
• Large user base with established authentication workflows

What We're Seeking:

I'd love to hear from others who have navigated similar transitions:

Migration Experiences:

• Has anyone here led or been part of a large-scale ADFS migration?
• What were the biggest challenges you encountered?
• How did you handle the transition timeline and user impact?
• What lessons learned would you share?

Solution Comparisons:

• Microsoft Entra ID (Azure AD): Experiences with hybrid deployments, cost implications, feature gaps vs ADFS?
• Third-party solutions (Okta, Ping Identity, Auth0, etc.): How do they compare in enterprise environments?
• Other modern alternatives: What else should we be evaluating?

Practical Considerations:

• Cost analysis: Hidden costs beyond licensing?
• Integration challenges with legacy applications?
• Change management strategies that worked well?
• Security and compliance considerations during migration?

Specific Questions:

1. For those who moved to Entra ID - was the cost savings as significant as Microsoft claims?
2. Any experiences with running parallel systems during transition?
3. How did you handle applications that were tightly coupled to ADFS?

Any insights, war stories, recommendations, or cautionary tales would be incredibly valuable as we plan our approach.

Thanks in advance for sharing your experiences!

We've been running a cross forest trust with Selective Authentication for over a decade. Call the domains A and B. Both domains are at the 2016 functional level and schema version 88. ADFS, running on Server 2016 and living in Domain A, was introduced approximately six years ago to support a business-critical application. Everything was working fine for those six years.

Several weeks back, we started the process of upgrading the ADFS infra to Server 2022. 2022 server was made primary at that time. All went well.

Late last week, we shut down the last 2016 server in the farm for a scream test. All went well.

One morning earlier this week, that 2016 server was fired back up, the ADFS role uninstalled, and the server removed from the farm configuration. Everything still seemed to be working OK, at that point.

Later that afternoon, the FBL was raised from version 3 to 4. It appears to have been at this point that ADFS started logging 0xC0000413 errors in event 4625 when users in Domain B logged in. Instead of letting them into the application after they provided valid credentials, they'd just get redirected back to the ADFS login page.

The 4625 events showing the 0xC0000413 errors are on the ADFS server, and show the ADFS gMSA for the "Subject" section, but NULL SID for the "Account For Which Logon Failed" section. They show up immediately after 1202 4624 success events for the login of the Domain B user.

After finding some old discussions regarding similar problems, we set Domain A's trust of Domain B to forest-wide, as a test. Logins for users in Domain B then started being processed as normal. We don't want to leave the trust in this state, though.

The Domain B users are all in a group that already has Read and Allowed to Authenticate permissions on the ADFS servers' AD computer objects.

I don't get why changing Domain A's trust of Domain B to forest-wide has any effect:

• The failure being shown is for a gMSA in Domain A logging into a computer in Domain A, nothing from Domain B is referenced in the failure event
  
• The user in Domain B demonstrably has permission to log into the ADFS server, as evidenced by the 1202 and 4624 events
  

Anybody have any idea what the heck I'm missing here?

Hi, ive inherited a client that has a legacy application using ADFS, the token-decrypting cert and token-signing cert has expired and wont let me renew them.

I get the following, any help would be appreciated

PS C:\Windows\system32> Update-ADFSCertificate –CertificateType token-decrypting –urgent

Update-ADFSCertificate : The server was unable to process the request due to an internal error. For more information

about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the

<serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or

turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.

At line:1 char:1

Hey All,

My work is wanting to migrate from a 3rd party MFA provider to using MS Authenticator and my god it has been a dumpster fire. Really hoping one of you knowledgeable people have experienced this before as MS Premier support have been clear as mud.

Our AD is 20+ yrs old and our username/UPN format was built up using a number scheme on which all the user onboarding/off boarding and HR (and god knows how many bespoke) systems have been built. Against current MS recommendations, our users UPN and email address are not the same and never will be while the above is in play (large org, hence silo'd and hard to get change moving).

Anyway, roll forward and I'm trying to get MS Authenticator working with our ADFS farm (V5 FBL 4) and am finding that despite the user being registered for MS Authenticator on their device for our tenant, they are always returned with a "no authentication methods available" error when secondary auth is triggered from ADFS.

I logged an MS support case who quickly identified that we have the AlternateLoginID attribute enabled and set to mail. I didn't even know this existed (original ADFS env pre-dates me), and short version from my understanding being ADFS will use the users mail attribute for the LDAP lookup to AD for primary auth, however when going to MS Authenticator in Entra it falls apart as the MS Authenticator service is Entra is pinned to the users cloud UPN (which is different per above).

Our options are to make the on-prem UPN and email address the same (never going to happen) or remove the AlternateLoginID to force ADFS to do primary auth with the UPN only. There is also the Alternate Logging ID preview for Entra ID which seems like it might work, however the org won't go for that until it is GA. I have tested the the removal of the AlternateLoginID successfully and asked MS for assistance in getting more detail on how to determine impact.

MS support have not been able to provide any clear information on what the end user or systems impact will be from removing this attribute or how to gather such information. The only metric identified for even registering AlternateLoginID use is a Windows Performance Counter which obviously tells us nothing of users or consuming apps. I'm also having a whale of a time trying to get my management/project to understand that a user inputing their email address when prompted is not what AlternateLoginID is, however because documentation from MS on this is pretty limited and the ambiguity of language coming from MS support, I've got nothing to point them too so they can read and understand in layman's terms.

My gut feeling is it is low risk, however because this entire environment is so ancient and seemingly there is no data I can collect to back it, I am feeling pretty uneasy about it. Just wondering if anyone else has been snagged by this issue and how it worked out? Any gotchas with random auth issues post AlternateLoginID deletes, or did you go another way?

Hey there,

I am having this strange issue when adding a new server to an existing ADFS farm. No matter what I do, it keeps throwing a "System.Data.SqlClient.SqlConnection" error, which is weird because I am not using a SQL Server for the ADFS configuration. The existing farm uses Windows Internal Database. I have spent 3 days trying everything I can think of and there are no solutions anywhere online. I am a Network and Systems Engineer, so believe me when I say I have tried everything. Please see the list of things I have tried. There is also a screenshot of the error I am receiving. The servers are on our domain and the ADFS system is live and working fine. The farms use a group managed service account. All traffic is allowed between the servers. I am seriously out of ideas, so posting here. Thanks for any help!

The Error Message:

An error occurred while checking if the database exists: An error occurred during an attempt to connect to the AD FS configuration database. Error: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.. Confirm that the database hostname and instance are correct and that the specified service account has logon access to the database.

Troubleshooting steps I have tried:

• Fresh install of Windows Server 2019, 2022, and 2025
• Tried creating completely new farm
• Checked Group Policy
• Checked Group Managed Service Account
• Set ADFS service to use GMSA
• Updated Windows Server with latest updates
• Installed .NET 2.0, 3.0, 4.6, 4.7, 4.8
• Installed WID service
• Installed IIS service
• Turned off Windows Firewall
• Allowed all traffic between servers on network end
• Ensured servers can communicate to other servers via Test-NetConnection
• Installed dedicated certificate on new servers
• Gave read permissions to certificate private key for GMSA
• Backup and Restore using Microsoft's dedicated ADFS Backup & Restore tool
• Copied WID data files onto new server
• Edited local group policy to allow logon of services
• Ran things as administrator

We have ADFS setup on a Windows 2016 server which the token signing certificate is expiring soon. Even though the auto renew is enabled, it's never worked properly in the past so we've always had t o manually renew the certificate. With Microsoft depricating/ending support for the MSOnline module, has anyone been able to manually renew the token signing/decrypting certificates with Graph

These were the steps we used to take to renew the token certificate:

1. Powershell as administrator and run the commands

2. import-module msonline

3. connect-msolservice

4. Get-MsolFederationProperty -DomainName contoso.com | FL Source, TokenSigningCertificate

5. $cred=get-credential

6. connect-msolservice -credential $cred

7. update-msolfederateddomain -domainname contoso.com -SupportMultipleDomain

8. Get-MsolFederationProperty -DomainName contoso.com | FL Source, TokenSigningCertificate

Say you have a domain, example.com and one public IP address (e.g. a lab environment). Could you do a setup like this:

• adfs.example.com resolved via internal DNS leads to the ADFS servers directly & all works normally
• adfs.example.com resolved via public DNS leads to your public IP
  • Port 443 goes to a general purpose IIS server
  • the site bound to that hostname is just a redirect to adfs.example.com:444
  • Would the client then re-make its original SAML request to adfs.example.com:444 (which could be forwarded on your firewall to port 443 on the ADFS Proxy?)

Or, does ADFS really need its very own public IP where port 443 is not shared with anything else?

I am trying to get ADFS to work with Google. I inherited a network that had AD, Azure, Google, and Apple all using unique domains and passwords. I have ADFS and sync azure and google now. Once these all work I will federate apple too.

In adfs I set up a relying party trust with google. I can try to login in. If I use a bad user/pass combo i am told my credentials are bad. If I use the correct credentials i do get passed back to google but it says it couldn't log me in.

The SAML response is base64 and when I decode that i can see my server name, the correct google SAML websites, the correct nameid, the correct certificate, etc... I just can't seem to figure out why google gives me the error. I thought I would start on the adfs side.

Any suggestions on what to check next?

We've been using AD FS with Azure as the MFA method for years. Suddenly at 6:30pm EST we started getting reports of users being unable to sign into services. When they try to authenticate, they get properly redirected to the AD FS login page, which then sends them to the MFA prompt. However instead of the proper MFA prompt, it says "For security reasons, we require additional information to verify your account", and then redirects the user to their Microsoft account info on the security tab. Oddly enough, we have some services that SSO directly through Azure and require MFA, and those work without issue. As does logging into Azure and Microsoft 365. It seems to only be impacting services getting sent to the MFA prompt from our AD FS servers. We've had this in use for years now without issue, and I'm not aware of any MFA-related changes that went into effect today. Any idea what might be going on here?

Anyone else seeing this warning event on their ADFS servers? To me this reads like the ADFS server could not serve the metadata.xml file to one of the clients that request it. Reason being that the HTTP response is too large or something as seen in the exception details.

Is this something I can fix? Someone played around with the webserver settings on ADFS?

The Federation Service was unable to create the federation metadata document as a result of an error. 
Document Path: /FederationMetadata/2007-06/FederationMetadata.xml 

Additional Data 

Exception details: 
System.Net.ProtocolViolationException: Bytes to be written to the stream exceed the Content-Length bytes size specified.
   at System.Net.HttpResponseStream.Write(Byte[] buffer, Int32 offset, Int32 size)
   at Microsoft.IdentityServer.Service.FederationMetadata.SamlMetadataListener.OnGetContext(IAsyncResult result)

We have an existing Azure AD tenant named toto.

Users (@toto.com) are synced from our on-prem Active Directory to the cloud via Azure AD Connect.

We also have ADFS in place to federate our domain (toto.com) with the toto tenant.

Now, we’ve created a new Azure tenant called fofo, and we want to sync users (fofo.com) from the same on-prem Active Directory (they exist in this AD) to this new tenant (fofo) as well.

Question:

we know we should use a different AD Connect isntance but can we use the same ADFS infrastructure, or should we set up a separate farm?

I know we get 2 different options from a URL perspective. Either we get to use the same hostname but have to use a non-standard port, or get to use port 443 for everything, but have to use 2 separate hostnames, with certificate authentication happening on certAuth.<federation farm fqdn>. Is there anyway to customize the URL to not be certAuth?

I am a complete ADFS noob. But I am working on setting up AD FS and WAP internally to test some functionality before we move the WAP to the DMZ. But I need help with configuring this to work. Currently the AD FS host name is adfs.domain.com and I want access to AD FS via the WAP with adfswap.domain.com. So I need to create an application in remote management for this. And what would the certificates be that I use for configuration of the WAP.

Currently our certificates look like this:

AD FS cert: CN: adfs.domain.com SAN: enterpriseregistration.domain.com

WAP cert: CN: wap.domain.com SAN: adfs.domain.com Is this one correct? I see online I should use the AD FS cert this config but how would I be able to use the wap.domain.com hostname to access

We're having a really weird issue with our ADFS server that we've been trying to diagnose all day but getting nowhere. Since first thing this morning, when signing into ADFS via its web page, it accepts the credentials given, but then immediately just loops back to the login page. No matter how many times we log in, it just goes back round in an infinite loop and never progresses. The server was working without issue yesterday.

Authentication using SSO that doesn't touch the web page is still working. This is only affecting services that redirect to the web page.

Browsing to https://[server.domain]/adfs/ls/idpinitiatedsignon.aspx presents the same symptoms. The federationmetadata.xml file is reachable at the usual URL without issue.

Nothing is logged in any event log when this happens. No error messages are displayed to the user.

Credentials are still being authenticated to our DCs successfully. When we tested by entering bad credentials on purpose, it returned a bad password error as expected.

Our signing and encryption certs are current. The new certs were generated and rolled over last month, and the old certs expired on Monday. That said, the fact that the internal idpinitiatedsignon.aspx is also broken is telling me that it can't be cert related.

We initially thought it was to do with patching and restored a backup of the server from three days ago. The restored server behaves exactly the same.

I've tried searching online for the symptoms, but everything I've found is a) years old, b) has slightly different symptoms (eg. entries in the event log that we aren't seeing), and c) appears to have been caused by unrelated config changes.

Nothing has been changed at all to the best of our knowledge, other than Windows updates being installed.

Server is a Windows Server 2016 VM on an on-prem AD domain. There is a sync up to 365 using Azure AD Connect, but all of that happens on a different server. Our ADFS server never touches 365/Entra.

We're at a complete loss. I would massively appreciate any guidance.