I have problem, that when I'm trying to setup "autoconnect with Use Desktop Credentials" option.
all the time is cached domain info as well instead of just "username", which is required.
I get "domain\<username>" instead of "<username>" and this cause login failed.
how to make it working? is there some possibility to ignore that domain info or how to set authentication to require domain during login procedure?
Can you expand further on what you are seeing?
Are you using AD/NT or RADIUS as your auth server?
How are users logging in to their machines?
Does changing to credential provider change the behavior/meet your need?
If your user is coming from a workstation that is NOT a member of your domain, then domain\<username> where domain is the actual domain name (Contoso\<username>) is a valid and helpful configuration. If your users are coming from domain joined workstations, then domain\<username> will not be a requirement.
well, user's have company laptop, when login to windows, he is of course using domain username and password. so domain is pre-defined - no local account, just domain.
let say, I'm from company OTT, name Johny Fencer, username johnyf
to windows, I'm using just johnyf + AD password - of course, no lonal dogin, but domain account, domain OTT is pre-defined under login screen
to VPN I'm using just johnyf + AD password - so basickly the same login credentials as for VPN
but if I enable in PS VPN profile use desktop credentials, login fail, because as username is pre-filled "OTT/johnyf" instead just "johnyf".
and need to help:
1: how to set client to accept username with domain credentials in name
2: how to remove this domain from username
on SSL VPN GW is used LDAP as primary auth.
We are facing a similar issue and as a workaround we use an ExtensionAttribute field in the AD server to contain the value <DOMAIN>\<USERNAME>, and specify the following filter for finding user entries in the LDAP Authentication Server configuration:
Offcourse AD needs to be adjusted to have the correct values in the ExtensionAttribute field, so this might end up as an administrative, fault sensitive approach on the long run, especially in environments with a lot of users. Some automation/script needs to be in place to make sure that the ExtensionAttribute field is populated also for new users added to AD, or when a username needs to be adjusted (e.g. due to marriage/divorce: surname change...).
And in our case this is only 50% of the solution as the 2nd factor authentication server (RADIUS) does not accept usernames prepended with "<DOMAIN>\". So if we want to make this work, we should also change Radius server to have the usernames prepended with "<DOMAIN>\".
We also tried using UserPrincipalName (<username>@<realm>) instead of SamAccountName, but in that case Windows prepends the username with a backslash...
It seems that for PulseSecure UAC product there is an option to "strip domain from Windows username"; see https://docs.pulsesecure.net/WebHelp/Content/PCS/PCS_AdminGuide_8.2/Configuring%20Authentication_4.h... but that is not available for PCS.
We have a support case open for this issue at PulseSecure at the moment so hopefully there will be a solution...
Hi @mwarnier - just wondering if you were able to find a solution to strip the <DOMAIN>\ portion from the Radius request? Many thanks
Don't worry - sussed it, looks like this option is now available!