> On 22 Mar 2019, at 23:46, Zombie fork <forkzombie@xxxxxxxxx> wrote: > > Hi, > We are trying to explore new methods of authentication. We want to move away from the traditional password based authentication to a more secure method like using Certificates , keys etc. > > Is it possible to implement this? What alternatives do we have? > > Can this be applied on a specific user, ou , subtree etc. > > Is there any documentation around this? The issue is that there are limitations of the LDAP protocol and PAM, so many options are removed from you. You then have to break the problem to three spaces. * Authentication to workstations (physical access) * Authentication to remote servers (ssh etc) * Authentication to applications (websites etc) So let’s break these down: * To workstations: Certificate authentication can be configured to linux workstations with SSSD with steps found: https://fy.blackhats.net.au/blog/html/2018/02/27/smartcards_and_you_how_to_make_them_work_on_fedora_rhel.html?highlight=sssd You can use TOTP/HOTP however there are security risks related to this due to a requirement to distribute the OTP private material to the workstation it self. All workstations should be supplemented with full disk encryption to mitigate this risk. * To servers Use SSH key distribution in LDAP via SSSD. * To websites For this, certificate auth is a webserver + browser issue, and optimally, you would actually use something like oidc/saml via a project like ipsilon or other web based providers. There is a theme here: LDAP is *minimally* used in the authentication process (if at all) and is transformed into a mechanism for the distribution of public authentication components (ssh public keys, public certificates etc). Finally, it is my personal opinion (IE not the opinion of the project or my employer) that kerberos should be avoided as it introduces complexity, fragility and high risk of lateral movement attacks. Kerberos is basically the reason why windows networks are trivially attacked and allows lateral movement. I strongly advise that it should not be used. > _______________________________________________ > 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
