![]() ![]() Mail: domain admins, Groups, directory.nhĭn: cn=domain admins,ou=Groups,dc=directory,dc=nhĭn: uid=fred,ou=People,dc=directory,dc=nh HomeDirectory: /var/lib/nethserver/home/admin LoginShell: /usr/libexec/openssh/sftp-server Running ldapsearch from the CentOS machine seems to work: log]# ldapsearch -x -b dc=directory,dc=nh -H ldap://192.168.1.52ĭescription: ldapservice management accountĭn: cn=locals,ou=Groups,dc=directory,dc=nhĭn: uid=admin,ou=People,dc=directory,dc=nh The Neth box is using local OpenLDAP as the accounts provider. For now, I’m running LemonLDAP on a CentOS 7 VM, and Neth 7.9 on a separate VM. So I’ve been playing with LemonLDAP::NG a bit, and it’s looking nice, but right now I’m having trouble getting it to talk to a LDAP server on a Neth box. Feel free to suggest rows to add or corrections (unless a mod can make this a wiki post): Here’s the start of a comparison table among the F/OSS products I know of. Other software would take some research.Nextcloud is reported to have good support for SAML.Gluu (we already have the beginnings of a how-to on Gluu at How to install Gluu server, and I’ve been able to configure Gluu to pull users from Neth’s LDAP installation)ĪFAIK, all of these can authenticate against the LDAP database Neth is already using (being able to add users to that database, as Martin had been asking for, seems less common), so user creation wouldn’t necessarily need to change, but we would need to investigate having all of our other web apps use one of these other authenticators.I think the security benefit still makes them worth some investigation, and there are (as I said above) a few F/OSS options. Many web apps don’t support more involved authentication mechanisms like SAML or OIDC. ![]() Complexity of configuration–both for the SSO software, and for the client app.So why aren’t we using them already? I expect there are a few major reasons: In addition, they typically support authentication mechanisms like SAML and OpenID Connect, allowing them to handle additional scenarios that LDAP won’t handle (the particular one I have in mind being using Step CA to issue SSH certificates). And if you want to use hardware authenticators like YubiKeys, Nextcloud doesn’t need to support FIDO2, U2F, or whatever. Nextcloud never sees your password, so it can’t leak it. When you click the Login button in Nextcloud, for example, you’re redirected to the SSO app, which authenticates you (including 2FA if desired), and then returns you to Nextcloud. And if you want to implement 2FA, each application needs to support it, and you can only use the methods supported by that application.īy contrast, the SSO application handles authentication directly. But…Įvery application that requires login is now at risk to compromise user credentials, because each of those applications handles those credentials. It’s fairly simple, it’s widely supported, and it’s pretty easy to implement. Applications take the username and password, validate them against the LDAP server, and grant access. Right now, Neth uses LDAP (either a local OpenLDAP server, a remote one, or AD) for authentication. There appear to be a number of F/OSS solutions in this field, and it’s looking like it’s something that could improve system security quite a bit. ![]() So as is often the case, one thing leads to another, which leads to another, and now I’m starting to look at SSO/IAM software. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |