CirrostratusHello,
I configured an F5 App using Kerberos Authentication along with Azure AD. But at the moment I want to make the same App ready for NTLM Auth using Azure AD.
Reference Doc I am following is this. Question is how/what I need to modify to change it to NTLM Based from Kerberos Based Application.
https://blog.azureinfra.com/2019/04/29/f5-big-ip-aad-basic-ntlm/
MVPcan't tell you from my mind fully, but as you already have Azure AD setup with Kerberos working and you have a good guide for Azure AD setup with NTLM, can't you compare the two and work it out?
or even build the NTLM one next to your current one and move over once it works?
the big difference will be that you need to ask for the password as that is needed for NTLM and not for Kerberos. your SSO object will change from Kerberos to NTLM or Basic as shown in the page you. Which means your backend server will also need to allow one of those.
CirrostratusActually Kerberos one was not working it was setup and when tested it did not work and Backend App was not ready for Kerberos hence whatever configured for Kerberos trying to move to NTLM.
When user tries it shows error as attached. Please advise if you get a hint from it.
One quick note is when user tries they get the Microsoft Landing page , they try to authenticate using email address and I have been told they have to try using email address as user name. However user tested with "DomainName\Username" it did not work too. Azure side they see the log for Authentication as passed but I see error at F5 side as attached.
I will also match as you mentioned above.
MVPa quick search on the error throws up a couple of possible leads, this one seems most useful to check:
https://www.devcentral.f5.com/s/question/0D51T00007HRNdd/authentication-via-azure-ad-blocked-by-access-policy
Cirrostratusi do assume you assign session.logon.last.usernameUPN in the SSO mapping object? -- Sorry Where do I check this ?
MVPSSO Credential Mapping VPE, though i now see you use it in the SSO element
so it is fixing that mapping, session.saml.last.attr.name.Identity sounds logical, did you already try that? still be to look into your APM session variables to double check.