User creation from Portal creates a user account with email addresse name (containing blanks) ?

Hey Jurgen,

My XG is the same - firstname.surname@internaldomain.int

I set my STAS to pick DC=internal domain, DC=int

It does pull the email address from the AD credentials though - do you have all users set up with the email field populated in the Properties of the user in AD?

I haven´t installed STAS.
I only added the domain controller and importet the main user group.

If it pulls the email address, from which attribute would the be?

My mail adresse is surname.name@company.de (.local)

either i need full email as a username or strip all after @company....

Hey Jurgen,

Sorry I thought you had STAS configured as it reads your AD and automatically pulls users as they login to their PC's.

How are your users authenticating? Do they enter user / pass in a web portal?

The user is not known to the XG!

I open the user portal from Chrome or IE Browser.

Next i enter my netbios login with a password and the user is created like "john smith@company.local.de"
The email address is not used at the creation.

email would be "john.smith@company.de"

Oh OK - I would suggest you look into STAS as this way you don't need to import anyone and you can add the users to groups in AD that you can control in the XG if you have a business requirement.

For example in my group we have User and Elevated - users get the basics but no Social Media etc and Elevated gets everything except Nasty files like exe, jar, vbs etc

This way we restrict access and also get reports on user activity  - not machine activity.

Sorry I cannot answer your other question as STAS does the email field OK

Thanks,

i thought i don´t need STAS on my AD Server

Will this work with Windows 2019 and Domain Level at 2019?

I cannot clearly tell you the root cause for your issue, but i can explain you, how the Access_server( XG aua) works. 

If you setup a authentication server (AD) in XG, you have to define the netbios and the FQDN. 

Lets build an example. Domain FQDN: test.local, Netbios=test Usersyntax: surname.name

You simply authenticate to XG with any method (like user portal) with surname.name. 

XG will take this and verify this account to AD. It simply paste the FQDN to the request: surname.name@test.local  And the AD will tell you: Yes/No. Afterwards, the client will be authenticated. XG uses the SAMAccountname. 

If you use surname.name@test.local, it will work, because the access_server simply use the full string to the AD. 

This is build for Multi AD support. 

Now the best part: Which Field in AD uses XG to get the attribute "Email"? 

This is the attribute field in AD. You can verify it by expanding the AD view.

https://social.technet.microsoft.com/Forums/office/en-US/2c6e4e02-b942-453a-a09b-bbc5378d3db1/ad-custom-field-view-gtgt-advanced-features-attribute-editor?forum=winserverDS

You can motify it and let XG update the emails. Maybe this field (default mail) is not correct in your ad? 

Next point is: Yes the Domain in your account name is normal and by designed. It is to create a multi ad Environment. But as mentioned early, you do not have to use it. All authentication methods works fine without using the Domain FQDN. 

Hope this helps. 

Thanks LuCar Toni

i didn´t enter anything in

Display name attribute
Email address attribute

Now i checked my AD attribute and it makes sense to enter here

Display name attribute = displayName
Email address attribute = mail

The user will be created with the correct email and display name now.
But the User name still has "john smith@company.local.de" 

The SAMAccountname is indeed surname name and if XG adds the domain @company.local.de it looks strange ..

As mentioned above. It is ok and better way to do it with the FQDN in the user name. 

Because think about multi domain customers. You cannot guess, which AD this user came from, if you do not use the FQDN in the user name. 

And the user do not have to use it. They can continue to use just the user name. XG will take care of the authentication with the correct domain fqdn. 

From my point of view, this is the better approach in the long term. 

if i understand correct ..
if my domain ist domain.local.de

i coud log in with surname.name@domain.local.de in the user portal?

I tried and it doesn´t work.

My logon account in AD is set to a differnent UPN and i can´t login with it.

surname.name@company.de