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:
>
> 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?
(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(a)lists.fedorahosted.org
>> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
>>
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org