importing AD users cuts off the username

[Jhjacobs81]

So, i have setup OPNSense to authenticate our IT staff against Active Directory. It works in so far that it does import the correct users. i set the "User naming attribute" to email, but when i log in it doesnt work.

When i use the tester and i input jhjacobs81@emailadress.com it validates.
When i login to the administration website it does not. i have to input jhjacobs81

i would want everyone to use their full emailadres, because we use that everywhere when we use SSO ;-) does anyone know how to fix this?

[Cerberus]

It looks like a bug to me. I tried it myself by using "userPrincipalName" as Usernaming attribute. On import it shows the users email address but on grouping it shows the sAMAccountName value.

Update: this only affect user login into opnsense and not using ldap as authentication source for ipsec/openvpn, these components respect "userPrincipalName".

[mimugmail]

Worth opening an issue in GitHub

[franco]

For reference, the maximum user name length in FreeBSD is 32. See https://github.com/opnsense/core/commit/0829a34cef4

I will check the GUI login though...


Cheers,
Franco

[franco]

PS: Did you set web GUI to local database? Probably only need to enable LDAP authentication for GUI as well (System: Settings: Administration).

[Fright]

@franco
it looks like the script cuts off the domain part before saving the account to config
(line 117: https://github.com/opnsense/core/blob/master/src/www/system_usermanager_import_ldap.php)
did not check how it will work if domain part is saved.

[franco]

Yes, to avoid tripping over the 32 character limit...


Cheers,
Franco

[Fright]

@franco,
got it, thanks
sorry, not topic-starter (and I don't think it's a good idea to use ldap for GUI-auth), but let me explain if I understand correctly:
everything works fine if its single domain network.
if there is a Active Directory forest with child domains, it is logical to use the Global Catalog and in this case authentication is working  using the userPrincipalName attribute (which includes the domain part). It works well for OpenVPN etc. but not for GUI.
(and what's more, I don't see the user bind to the authentication server in config if multiple servers are configured)
(https://forum.opnsense.org/index.php?topic=19078.0)

[franco]

Good point. The local import is not the best place to join multiple domains. It is more for flexibility in small use cases where you need it. Larger setups work fine with direct authentication against multiple LDAPs and there is probably also other equipment dealing with VPN etc. so that local import does not have to be a perceived bottleneck.


Cheers,
Franco

[Fright]

could you give more information about "Larger setups work fine with direct authentication against multiple LDAPs " please? i think i don't understand what you mean

[franco]

If you set the web GUI to authenticate against LDAP (not only Local Database) you don't have to import from LDAP and authenticating with email works fine.


Cheers,
Franco

[Fright]

wow! forgot about this. will test, thanks! (group matching did not work when I checked it at the very beginning on 19.7. I will dig deeper)

[Fright]

@franco
I tested and it looks like the import of the user is still necessary (without this authentication works, but there is no authorization: "No page assigned to this user! Click here to logout")
it is not necessary to include the user in the authorization groups (groups are synchronized via LDAP after login), but the user must be imported ..
sad (it would be great if imports were not required at all.On the other hand, it is dangerous with an accidental vulnerability when the OPN group accidentally coincides with the LDAP group)

[franco]

Ok, but login works ;)

That's indeed an issue that prevents designated use. We added email address field a while back and one could use this to authenticate as well but the problem is there was no structural enforcement to email address. It could still be done but we have to prevent login for ambiguous address (given more than once) and properly import the email...

Same accounts for different domains will still clash, but I would rather see this out of scope than trying to address this as well (the UNIX model does not fit here and overlapping user aliases across domains are probably the same person anyway).


Cheers,
Franco

[Fright]

yes, authentication works )
but GUI still not working without authorization  ;)
it seems to me that the mention of the email is somewhat confusing. it's not necessarily about email, but about the used ldap attribute. it may not be samaccountname or email.  as i mentioned when using AD GC the userPrincipalName attribute is used (just to prevent overlapping usernames in different domains. userPrincipalName include @domainpart and may or may not coincide with the email).
the idea of authorization without importing a user seems very interesting to me for this.
I don't know if I can find this part of the code (authgui.inc ?) and test this possibility
(another possibility is not to sanitize the username on ldap-import? since imported ldap user have <user_dn> parameter in config, it can be skipped when user checked against local db?)