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?
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".
Worth opening an issue in GitHub
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
PS: Did you set web GUI to local database? Probably only need to enable LDAP authentication for GUI as well (System: Settings: Administration).
@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.
Yes, to avoid tripping over the 32 character limit...
Cheers,
Franco
@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)
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
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
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
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)
@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)
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
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?)
Let's call it username alias then... it still needs to be a well-defined field (email is the most common) and it must be unique to work and then you also have to prevent overlapping alias and real other user names (uh-oh, easier with email vs. clear username to double-check).
Maybe the group matching can be used to just steer the authentication from a remote LDAP user to a local group with the proper GUI privileges? You still need to set this up locally, but don't have to deal with user imports at all.
Cheers,
Franco
Thank you for your patience. I seem to begin to understand. :D
So another question: why bother creating a local account ('/usr/sbin/pw ') for the ldap-imported user if integrated auth enabled, and not just writing to the config only?
this would remove the OS-restrictions for ldap-accounts?
QuoteMaybe the group matching can be used to just steer the authentication from a remote LDAP user to a local group with the proper GUI privileges? You still need to set this up locally, but don't have to deal with user imports at all.
yes i thought it worked like that when you mentioned it, but LDAP/ACL php-scripts seem to be hardcoded to the user in the config (so authenticated user
should be in config to get\sync privileges)
@franco
I quickly tested the idea: added a check for non-empty 'user_dn' before calling local_user_set (dont create local user on ldap import). This works with arbitrary ldap username (userPrincipalName with @domainparts in my case).
groups are synchronized via LDAP after login, privileges sets and user can work with GUI .
so the question remains:what is the purpose of registering ldap-user in the local database ('/usr/sbin/pw ') and what is the risk of skipping it?
That sounds like progress. :)
The reason is shell access (console or SSH).
Cheers,
Franco
logical, thanks!
in this case (with preservation of shell access) this feature requires too complex changes with unclear benefits
I have no more ideas ;D