A big thanks to @murrant who has done an amazing job in updating the AD auth module to support bind accounts, this means you can now make full use of the API tokens and alerting to emails gathered from AD - to do this you do need to update your config to make use of the new bind feature.
I ran into this issue where the API token stopped working. I added a bind account, which tested successfully with /script/auth_test.php. I also regenerated the API token. However, I still get an error about an invalid token when testing with curl and after updating the key in Oxidized. The exact error is “API Token is missing or invalid; please supply a valid token”. Any ideas for something else to look at?
I don’t know if ./script/auth_test.php tells you if the bind is working or not but maybe it isn’t, you will still be able to auth without the bind, whether it will auth if the bind is configured and incorrect I don’t know.
@laf I’ve triple checked the bind user. Running auth_test.php fails using an incorrect bind account password. Looking over some of the code it appears that it’s supposed to add the remote LDAP/AD user to the database, and references that user_id for the api_token. However, for some reason my user account is missing from the database and it’s not creating a user account when trying with an otherwise unused account, even when generating a new API token for that user. I tried adding my account manually to the database and the API token still fails.
Is there a way to add a local user account to use specifically for the API token, while still using AD auth for everyone else?
@laf@murrant I found the problem. I set the auth_ad_base_dn to an OU. The OU does not have a SID. It appears the base_dn needs to be the root of the domain for this to work. If it’s not the domain root, then a default SID of “S-0-0” is returned. Once I changed that the API started working.
I have just tested user authentication via active directory and I can confirm that it works:slight_smile:
I noticed thought that everyone who is configured on AD can authenticate and that is a bit problematic for us as AD is not within our span of control. In our case we have a requirement that we only use AD for password authentication such that a user will need to exist on LIbreNMS DB for successfully authentication to occur. We also require that user permissions be dictated locally on the LibreNMS install rather than be controlled by user groups in AD. Is this possible in the current setup? Should I log a separate feature request for it?
Imho, this creates a blurred line between auth modules (yes we already have that blurred line with other auth modules) and I’m against it, it creates too much complexity and auth should be dealt with centrally.
We still want to authenticate centrally however have an ability to control what users can do or view on LibreNMS handled as a internal capability of the application. This works pretty in our other applications like Tacacs for instance where we authentication centrally but control everything else, i.e. user permissions, what commands users are allowed to run or not run, etc inside the Tacacs application itself.
So the basic idea here is that if users are created or defined inside LibreNMS then they should not be allowed to login regardless whether the authentication happens locally or is delegated to an outside service like AD.
Perhaps a feature request kind of input from my side is that LibreNMS be made to operate in two modes; the current mode; I will call it standard_mode which is how it authenticates users currently. Or an alternative mode; I will call this one advance_mode, where users permission are controlled locally and all external authentication service are used just for user verification provide they already exist on the application database.
I think this way you will create more flexibility in catering for different authentication scenarios LibreNMS user may encounter.
I have the same concern as what you posted here as our AD is out of my own control, so it won’t be easy for us a create a user group and maintain the members inside. So it will be a good idea to let AD only respond for the password verification but the user permissions is done within LibreNMS, this is actually how other system like Zabbix or Cacti acts. So would like to know if you have ever submit a feature request for it or any other update you have?
We have a large device install base and various groups of users we want to give access to certain devices. Fortunately we have gruped devices we monitor into several device groups, i.e. Cisco firewall, Cisco routers, etc. It would be tedious to map every single user to every single device we him/her to have access to.
Would it then be possible to use AD as you suggest and a user to a specific device group? That way we can cut our workload and maintenance by half.
