Hi,
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf. In our environment we have hundreds of servers and what I usually do is manually generate the password on a test server. I would like to automate ldap_default_authtok via a php interface or API. This is needed because we use one bind DN per server and I'd like to build a web portal where people can request new server bind DNs and randomly generated passwords.
Is there a way?
Thank you, Mario
On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:
Hi,
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf. In our environment we have hundreds of servers and what I usually do is manually generate the password on a test server. I would like to automate ldap_default_authtok via a php interface or API. This is needed because we use one bind DN per server and I'd like to build a web portal where people can request new server bind DNs and randomly generated passwords.
This is really not an SSSD question, but a generic deployment/configuration question, so whatever you use to push the configs to your server, be it puppet, ansible or something similar should work.
That said, please read the manpage of sss_obfuscate. There is really no security benefit of using obfuscated password versus a clear text bind password, especially since sssd.conf is only redable to root. The feature was really added to allow administrators to 'tick a box' in environments whose security guidelines forbid them from using a password in a config file (which is a good thing) but they can't move away from bind passwords to something better (which is a bad thing).
It might be better to consider authenticating using something like Kerberos keytabs.
Jakub,
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
1. An admin will build 10 new servers via cobbler and use puppet to deploy settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself. Each entry looks like:
uid=server1.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com [....] uid=server10.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com
3. SecurityTeam will manually add above entries into LDAP tree using ADS or shell scripts and generate random passwords for each of those 10 entries 4. SecurityTeam will connect to a test server and run sss_obfuscate 10 times to be able to get the value of ldap_default_authtok, paste each of those encrypted passwords into a secure tool and send it back to the admin who requested the changes 5. The admin has to input each of those 10 'passwords' into git so puppet/ansible can pick them up.
Is there anything more painful than the above? Too much manual work, delays in ticket processing, mistakes and so on. What I'm looking for is a way to generate ldap_default_authtok in encrypted format. The sss_obfuscate tool writes to sssd.conf, is there a way to redirect the encrypted password to stdout instead of writing to the config file ? Unfortunately plain text passwords are not an option in my environment - in case a server gets compromised . I know, this is a different topic - some of the servers have to have certain ports open to the world like 80, 443 because of business requirements. I guess I am trying to minimize the risk of a compromise against ldap server which is critical to the infrastructure because ldap authentication is used by internal applications like web portals and ssh across thousands of servers. One could argue that this is a slapd config but it still does not resolve the above.
Thank you
On 11/30/2016 10:07 AM, Jakub Hrozek wrote:
On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:
Hi,
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf. In our environment we have hundreds of servers and what I usually do is manually generate the password on a test server. I would like to automate ldap_default_authtok via a php interface or API. This is needed because we use one bind DN per server and I'd like to build a web portal where people can request new server bind DNs and randomly generated passwords.
This is really not an SSSD question, but a generic deployment/configuration question, so whatever you use to push the configs to your server, be it puppet, ansible or something similar should work.
That said, please read the manpage of sss_obfuscate. There is really no security benefit of using obfuscated password versus a clear text bind password, especially since sssd.conf is only redable to root. The feature was really added to allow administrators to 'tick a box' in environments whose security guidelines forbid them from using a password in a config file (which is a good thing) but they can't move away from bind passwords to something better (which is a bad thing).
It might be better to consider authenticating using something like Kerberos keytabs. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Wed, Nov 30, 2016 at 11:01:51AM -0500, Mario Rossi wrote:
Jakub,
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
- An admin will build 10 new servers via cobbler and use puppet to deploy
settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself. Each entry looks like:
uid=server1.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com [....] uid=server10.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com
- SecurityTeam will manually add above entries into LDAP tree using ADS or
shell scripts and generate random passwords for each of those 10 entries 4. SecurityTeam will connect to a test server and run sss_obfuscate 10 times to be able to get the value of ldap_default_authtok, paste each of those encrypted passwords into a secure tool and send it back to the admin who requested the changes 5. The admin has to input each of those 10 'passwords' into git so puppet/ansible can pick them up. Is there anything more painful than the above?
(Completely untested idea)
sssd supports including configuration snippets since 1.14. Maybe you could drop a configuration snippet with the per-host bind password into /etc/sssd/conf.d/ with contents like: [domain/yourdomain] ldap_default_authtok_type = obfuscated_password ldap_default_authtok = 0xdeadbeef
Too much manual work, delays in ticket processing, mistakes and so on. What I'm looking for is a way to generate ldap_default_authtok in encrypted format. The sss_obfuscate tool writes to sssd.conf, is there a way to redirect the encrypted password to stdout instead of writing to the config file ? Unfortunately plain text passwords are not an option in my environment - in case a server gets compromised . I know, this is a different topic - some of the servers have to have certain ports open to the world like 80, 443 because of business requirements. I guess I am trying to minimize the risk of a compromise against ldap server which is critical to the infrastructure because ldap authentication is used by internal applications like web portals and ssh across thousands of servers. One could argue that this is a slapd config but it still does not resolve the above.
Thank you
On 11/30/2016 10:07 AM, Jakub Hrozek wrote:
On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:
Hi,
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf. In our environment we have hundreds of servers and what I usually do is manually generate the password on a test server. I would like to automate ldap_default_authtok via a php interface or API. This is needed because we use one bind DN per server and I'd like to build a web portal where people can request new server bind DNs and randomly generated passwords.
This is really not an SSSD question, but a generic deployment/configuration question, so whatever you use to push the configs to your server, be it puppet, ansible or something similar should work.
That said, please read the manpage of sss_obfuscate. There is really no security benefit of using obfuscated password versus a clear text bind password, especially since sssd.conf is only redable to root. The feature was really added to allow administrators to 'tick a box' in environments whose security guidelines forbid them from using a password in a config file (which is a good thing) but they can't move away from bind passwords to something better (which is a bad thing).
It might be better to consider authenticating using something like Kerberos keytabs. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
We're running 1.13.3 with the exception of a couple of hosts where sudo rules are kept in ldap and where we had to install 1.14.2 from unofficial repos . We had to do that because of random sudo issues in 1.13. On prod I would rather stay on the same version as official repo and not 'contaminate' the OS :)
root@b[/etc/ansible/environments]# rpm -q sssd sssd-1.13.3-22.el6_8.4.x86_64
root@b[/etc/ansible/environments]# rpm -q centos-release centos-release-6-8.el6.centos.12.3.x86_64
I see there is no solution to script generating lots of encrypted passwords at once so I have no choice but to write custom code to save data to mysql, have a back-end perl script running on a test box connecting to the DB, running sss_obfuscate locally with DB entries and re-uploading them to the database where the users would pick them up via a web interface :-(
Thanks
On 11/30/2016 11:22 AM, Jakub Hrozek wrote:
On Wed, Nov 30, 2016 at 11:01:51AM -0500, Mario Rossi wrote:
Jakub,
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
- An admin will build 10 new servers via cobbler and use puppet to deploy
settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself. Each entry looks like:
uid=server1.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com [....] uid=server10.domain.com,ou=hosts,o=mydomain,dc=domain,dc=com
- SecurityTeam will manually add above entries into LDAP tree using ADS or
shell scripts and generate random passwords for each of those 10 entries 4. SecurityTeam will connect to a test server and run sss_obfuscate 10 times to be able to get the value of ldap_default_authtok, paste each of those encrypted passwords into a secure tool and send it back to the admin who requested the changes 5. The admin has to input each of those 10 'passwords' into git so puppet/ansible can pick them up. Is there anything more painful than the above?
(Completely untested idea)
sssd supports including configuration snippets since 1.14. Maybe you could drop a configuration snippet with the per-host bind password into /etc/sssd/conf.d/ with contents like: [domain/yourdomain] ldap_default_authtok_type = obfuscated_password ldap_default_authtok = 0xdeadbeef
Too much manual work, delays in ticket processing, mistakes and so on. What I'm looking for is a way to generate ldap_default_authtok in encrypted format. The sss_obfuscate tool writes to sssd.conf, is there a way to redirect the encrypted password to stdout instead of writing to the config file ? Unfortunately plain text passwords are not an option in my environment - in case a server gets compromised . I know, this is a different topic - some of the servers have to have certain ports open to the world like 80, 443 because of business requirements. I guess I am trying to minimize the risk of a compromise against ldap server which is critical to the infrastructure because ldap authentication is used by internal applications like web portals and ssh across thousands of servers. One could argue that this is a slapd config but it still does not resolve the above.
Thank you
On 11/30/2016 10:07 AM, Jakub Hrozek wrote:
On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:
Hi,
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf. In our environment we have hundreds of servers and what I usually do is manually generate the password on a test server. I would like to automate ldap_default_authtok via a php interface or API. This is needed because we use one bind DN per server and I'd like to build a web portal where people can request new server bind DNs and randomly generated passwords.
This is really not an SSSD question, but a generic deployment/configuration question, so whatever you use to push the configs to your server, be it puppet, ansible or something similar should work.
That said, please read the manpage of sss_obfuscate. There is really no security benefit of using obfuscated password versus a clear text bind password, especially since sssd.conf is only redable to root. The feature was really added to allow administrators to 'tick a box' in environments whose security guidelines forbid them from using a password in a config file (which is a good thing) but they can't move away from bind passwords to something better (which is a bad thing).
It might be better to consider authenticating using something like Kerberos keytabs. _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Mario Rossi wrote:
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
- An admin will build 10 new servers via cobbler and use puppet to deploy
settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself.
Your security team should come up with a good concept how to delegate server entry creation to the right admins.
There are existing approaches for OpenLDAP to achieve this:
https://www.ae-dir.com/docs.html#role-setup-admin
Ciao, Michael.
Thanks Michael,
I think this is the way to go - slapd config to allow certain groups to write to the tree via dn.regex. Thank you for the link. Mario
On 11/30/2016 02:50 PM, Michael Ströder wrote:
Mario Rossi wrote:
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
- An admin will build 10 new servers via cobbler and use puppet to deploy
settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself.
Your security team should come up with a good concept how to delegate server entry creation to the right admins.
There are existing approaches for OpenLDAP to achieve this:
https://www.ae-dir.com/docs.html#role-setup-admin
Ciao, Michael.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
Mario Rossi wrote:
I think this is the way to go - slapd config to allow certain groups to write to the tree via dn.regex.
Æ-DIR does not rely on host name convention or DIT structure because this is too inflexible in practice.
Instead the ACLs work their way along the EER which also allows more levels of delegation:
https://www.ae-dir.com/docs.html#eer
But this is rather off-topic here.
Ciao, Michael.
On 11/30/2016 02:50 PM, Michael Ströder wrote:
Mario Rossi wrote:
Thank you for the information. We use both Puppet and Ansible to manage our servers. Let me add more details:
- An admin will build 10 new servers via cobbler and use puppet to deploy
settings 2. The admin will create a ticket to SecurityTeam who manages openldap to create 10 new ldap entries for the server itself.
Your security team should come up with a good concept how to delegate server entry creation to the right admins.
There are existing approaches for OpenLDAP to achieve this:
https://www.ae-dir.com/docs.html#role-setup-admin
Ciao, Michael.
Jakub Hrozek wrote:
On Wed, Nov 30, 2016 at 09:41:51AM -0500, Mario Rossi wrote:
sss_obfuscate is used locally on servers to replace clear text passwords in sssd.conf.
This is really not an SSSD question, but a generic deployment/configuration question, so whatever you use to push the configs to your server, be it puppet, ansible or something similar should work.
That said, please read the manpage of sss_obfuscate. There is really no security benefit of using obfuscated password versus a clear text bind password, [..]
It might be better to consider authenticating using something like Kerberos keytabs.
Or use client certs with SASL/EXTERNAL.
Ciao, Michael.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Mario Rossi -
Michael Ströder