#1489 sss_obfuscate issues
Closed: Invalid None Opened 11 years ago by smt.

Two issues with sss_obfuscate (RHEL 6, CentOS 6); sss-tools 1.8.0-32

(1) sss_obfuscate changes the domain order as specified by domains= in the [sssd] section. The order should be preserved.

(2) an sssd perfectly working setup using a cleartext ldap_default_authtok fails to work when the password is obfuscated on some systems. The log says:

(Sat Aug 18 07:05:52 2012) [sssd[be[SAMBA4]]] [simple_bind_done] (0x0080): Bind result: Invalid credentials(49), Simple Bind Failed: NT_STATUS_LOGON_FAILURE

The ldap server in this case is samba4 DC.

On replacing the obfuscated password with the original cleartext password, the system works once again. The password that was obfuscated was correct. Replacing the obfuscated password with the value from another system that
does work has no effect.

On systems where the obfuscated password does not work, redoing the obfuscation has no effect: it never works.


First, an aside: please do not use the sss_obfuscate tool. It is virtually useless and provides zero security benefit. It was added to placate a customer who was paying a brain-dead auditor to review their use of the code. Obfuscated passwords are 100% reversible encryption. Anyone who has access to the sssd.conf can trivially reverse the password and get its plaintext password. They need only take a look at the well-commented source code of the sss_obfuscate tool. Given that the sssd.conf file is already forced to be readable only by root, the obfuscation is an unnecessary option that only gives an illusion of added security, we strongly recommend against using it at all.

Now, on to the reported issues:
1. That's actually pretty serious, and we need to correct that. Changing the domain order can alter the way we resolve conflicts with identical usernames in different domains.
1. Can you identify if there is any commonality between the systems where obfuscation is not working? I wonder if perhaps we're seeing a 32-bit vs. 64-bit bug in the decryption code. (i.e. we might be making an inappropriate assumption about the length of an integer).

Fields changed

rhbz: => todo

Fields changed

proposed_priority: Blocker => Undefined

Replying to [ticket:1489 smt]:

Two issues with sss_obfuscate (RHEL 6, CentOS 6); sss-tools 1.8.0-32

(1) sss_obfuscate changes the domain order as specified by domains= in the [sssd] section. The order should be preserved.

Hi,
I tried reproducing your issue but didn't manage to. I set up two domains and tried invoking sss_obfuscate -d "firstdomain" and -d "seconddomain", but the order was retained.

How exactly did you reproduced the bug? How many domains were configured? Can you provide a sanitized version of sssd.conf that broke for you?

The behaviour works as advertised for me and there has been no response from the reporter for over a week. Closing as worksforme.

Please reopen the bug if you can still reproduce the faulty behaviour.

resolution: => worksforme
status: new => closed

Fields changed

rhbz: todo => 0

Metadata Update from @smt:
- Issue set to the milestone: NEEDS_TRIAGE

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2531

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata