Forum Discussion
NimbostratusActiveSync access without domain name in Logon
Hi
We have a small problem with Active Sync for one of our customers. We have deployed Exchange ActiveSync using the iApp template f5.microsoft_exchange_2010_2013_cas.v1.5.1. Our system is running 11.6 HF3. We are only using ActiveSync for this customer.
This works for most users, but some get the login prompt constantly and they doesn't seem to be able to log in. The problem only occurs for users that doesn't have the domain name in their logon.
I have tried to add the domain using a Variable Assign in the Access Policy and added the expression: "session.logon.last.username = expr { "domainname\[mcget {session.logon.last.username}]" }" This Variable Assign action is added between Logon Page action and AD Auth action.
With the Variable Assign I get the error message: "AD module: authentication with 'domainname\username' failed: Client 'domainname\username@DOMAINNAME' not found in Kerberos database, principal name: domainname\username@DOMAINNAME. Please verify Active Directory and DNS configuration. (-1765328378)"
Any tips?
Regards Geir
7 Replies
Michael_JenkinsCirrostratus
Do you know if the problem lies on the authentication side of the F5 or on the Exchange side? You can check the session log for that user to see which branches were followed during the login process.
If those users were authenticating fine in APM (according to the logs), you might want to try putting the variable assign after the AD Auth (and AD Query if you're using that as well) and see if that helps. You could also set a custom variable to
instead and use that in yourdomain\username
.SSO Credential Mapping
Geir_Sandbu_342Thanks for the quick reply Michael.
I am not sure if the problem lies on the F5 or the Exchange side. The ActiveSync application is migrated from an ISA TMG solution. And it works fine there. The ISA TMG has a way of adding the domain name for configurations that doesn't send any domain information.
The users logged on correctly according to the session logs. But still they get the username/password prompt. I tried to move the Variable Assign action after AD Auth and before SSO credentials (So no AD query Action). According to the session log the username now becomes domainname\username and the user is authenticated. But no synchronization.
If I want to set a custom variable to domain/username and use that in the SSO Credential mapping, how and where do I do that?
amolariTry to do that variable assignment you did after the AD auth instead of before. Then keep the SSO Credential mapping set to the "Username from Logon Page"
- Michael_Jenkins
you could try adding a variable assign after the AD Auth and set something like
tosession.custom.domainusername
. Do you have an SSO credential mapping action in you policy there? If so, you could change the username field to[mcget {session.ad.last.actualdomain}]\[mcget {session.logon.last.username}]
instead.session.custom.domainusernameAlso, on the login page, make sure the checkbox is there to split domain from username (may not make a huge difference for you, but then again it might help with those who do use domain\username to not fail after this change)
- Geir_Sandbu_342
Hi guys.
I tried both of your suggestions.
Michaels approach gave me this error in the session log: "Rule evaluation failed with error: invalid command name "session.custom.domainusername""
The Variable Assign action was placed after AD Auth and before SSO Credentials. The username field was changed to session.custom.domainusername. And the split domain from username checkbox on the logon page was checked.
- Geir_Sandbu_342
I came a bit further with my troubleshooting. This is the Policy I am using right now:
The Logon Page action contains this Branch Rule:
expr { ([string tolower [mcget {session.logon.last.domain}]] contains "domain") }That trail works for users authentication with either domain\username or Username - Password - Domain.
If the logon credentials doesn't include the Domainname then the fallback trail from the Logon Page action is chosen. Access sessions following the fallback trail is being authenticated successfully towards AD, but still Active Sync is not working. The exchange servers presents HTTP 401 (Not authorized). The Variable Assign action inlcudes this expression (domain is the name of the customers domain):
The SSO Credential Mapping action contains default values.session.logon.last.domain = return {domain}I have tried to move the Variable Assign action in front of the AD Auth Action. But still no luck.
- Kai_Wilke
MVP
Hi Geir Sandbu,
you may add a "Default Domain Name" configuration to your Exchange Server or even directly to IIS. I guess, it would be the most effective way to solve your problem. No coding needed...
Cheers, Kai
