sss_obfuscate issues

[sssd-bot]

Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1489

• Created at 2012-08-18 13:36:41 by smt
• Closed as Invalid
• Assigned to nobody

---

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.

Comments

---

Comment from sgallagh at 2012-08-20 13:50:55

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.
2. 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).

---

Comment from jgalipea at 2012-08-20 15:52:38

Fields changed

rhbz: => todo

---

Comment from dpal at 2012-08-23 23:23:34

Fields changed

proposed_priority: Blocker => Undefined

---

Comment from jhrozek at 2012-08-27 09:51:55

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?

---

Comment from jhrozek at 2012-09-04 17:55:58

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

---

Comment from dpal at 2012-09-04 23:34:31

Fields changed

rhbz: todo => 0

---

Comment from smt at 2017-02-24 14:33:27

Metadata Update from @smt:

• Issue set to the milestone: NEEDS_TRIAGE

[smt]

Pagure users are not the same as GitHub users.