5 ms·

LDAP is a remote login provider, works through PAM-module and is nowhere near "lightweight" as it supposed to be. Also, it stores only one hash for original pas

LDAP is a remote login provider, works through PAM-module and is nowhere near "lightweight" as it supposed to be. Also, it stores only one hash for original password, not many. If you do not have cached version of auth info on the server and remote login provider is offline, you have big problems. I can't imagine a single reason why I will do remote login service for the root user on the front-end load balancing server of a high load project. shadowd is not remote login provider, it only serves /etc/shadow hashes for local and possibly offline use.

KaiserPro 11y ago
Sorry but no, this is just not the right way to do it. with SSSD there is no excuse for not using AD/LDAP. Having done both, shipping /etc/passwd and using AD, its far more effective, secure, and crucially stable to have LDAP/AD as the single source of truth. Its not like its difficult anymore, you can even buy in AD from AWS. (just don't try and do machine accounts, you're better off using puppet/ansible for that sort of thing.) Think about it, you wouldn't ship /etc/hosts anymore would you? why do the same with user accounts.
- seletskiy 11y ago
  I guess, you didn't address any single issue I mentioned. I don't see, why it's far more effective, secure and stable to have proposed stack as the single source of truth. Given the example, that we do not have LDAP stack already integrated into dev/ops process, it's seems like an overblow for me to integrate it from scratch because of it's massive configuration, maintenance and ugly design. The right way to do for me is simplicity and using tools, that offers solution for small problems; using overcomplicated bloatware doesn't seems to be right way to do, especially now, when we have that rapid growth in software development. I would ship /etc/hosts if there will be major performance impact of doing millions of DNS queries across network under high load. It depends on the concrete case.
  - KaiserPro 11y ago
    SSSD cache for as long as you need. If you don't have an auth server or network then you are in deeper trouble. (even AD can be n-tier active active) AD/LDAP allows SSO for everything ssh, bash, gmail, AWS console, etc. Because its a centralised, when someone leaves, or their account is compromised then its one place to change it. Crucially its one source of truth across the entire estate, not just for "servers" or "desktops" As for "massive configuration, maintenance and ugly design." Its really not. Also purity of design is not getting the job done. Your approach is ok if you only have a few servers and a handful of users. The point of ansible/puppet/salt/$other playbooks is that 90% of the work is done for you. All you have to do is input your users, and roll out the SSSD conf (after testing) Even by hand openLDAP isn't that hard. As for the rhetorical question about /etc/hosts you wouldn't because thats what nslcd/sssd/Program caches are for.
brazzledazzle 11y ago
I think a LDAP/LDAP+Kerberos backend is more secure for user accounts but I'd agree that the root password doesn't belong in it. But personally I think disabling the root account (like OS X or Ubuntu) makes the most security sense. You can always get into the account in single user mode.

KaiserPro 11y ago

Sorry but no, this is just not the right way to do it. with SSSD there is no excuse for not using AD/LDAP. Having done both, shipping /etc/passwd and using AD, its far more effective, secure, and crucially stable to have LDAP/AD as the single source of truth. Its not like its difficult anymore, you can even buy in AD from AWS. (just don't try and do machine accounts, you're better off using puppet/ansible for that sort of thing.) Think about it, you wouldn't ship /etc/hosts anymore would you? why do the same with user accounts.

seletskiy 11y ago
I guess, you didn't address any single issue I mentioned. I don't see, why it's far more effective, secure and stable to have proposed stack as the single source of truth. Given the example, that we do not have LDAP stack already integrated into dev/ops process, it's seems like an overblow for me to integrate it from scratch because of it's massive configuration, maintenance and ugly design. The right way to do for me is simplicity and using tools, that offers solution for small problems; using overcomplicated bloatware doesn't seems to be right way to do, especially now, when we have that rapid growth in software development. I would ship /etc/hosts if there will be major performance impact of doing millions of DNS queries across network under high load. It depends on the concrete case.
- KaiserPro 11y ago
  SSSD cache for as long as you need. If you don't have an auth server or network then you are in deeper trouble. (even AD can be n-tier active active) AD/LDAP allows SSO for everything ssh, bash, gmail, AWS console, etc. Because its a centralised, when someone leaves, or their account is compromised then its one place to change it. Crucially its one source of truth across the entire estate, not just for "servers" or "desktops" As for "massive configuration, maintenance and ugly design." Its really not. Also purity of design is not getting the job done. Your approach is ok if you only have a few servers and a handful of users. The point of ansible/puppet/salt/$other playbooks is that 90% of the work is done for you. All you have to do is input your users, and roll out the SSSD conf (after testing) Even by hand openLDAP isn't that hard. As for the rhetorical question about /etc/hosts you wouldn't because thats what nslcd/sssd/Program caches are for.

brazzledazzle 11y ago

I think a LDAP/LDAP+Kerberos backend is more secure for user accounts but I'd agree that the root password doesn't belong in it. But personally I think disabling the root account (like OS X or Ubuntu) makes the most security sense. You can always get into the account in single user mode.