FreeIPA 3.3.5 and sudo

The last time I had any real reason to play with sudo and IPA was before sssd got sudo support. I found the previous sudo-ldap debugging quite good, even if sudo itself was rather slow due to lack of caching.

A lot of users seem to have problems getting it setup since older IPA clients will not do this automatically so I thought I’d give it a go. I’m doing this on an up-to-date Fedora 20 system using the following IPA and SSSD:

freeipa-client-3.3.5-1.fc20.x86_64
sssd-1.11.7-4.fc20.x86_64

I started with the sssd-sudo(8) man page which laid out quite clearly the changes I needed to make to /etc/nsswitch.conf and sssd.conf. I restarted sssd and found my user couldn’t sudo at all, which makes sense since I hadn’t added any rules yet.

Ok, so I add a single rule to run any command on any host for a new group I added, sudoers of which my test user is a member. Oh, and be sure that the user is a member of the group before logging in so the groups evaluate properly.

I created the group and sudo rule with:

[admin@ipaserver]$ ipa group-add sudoers
[admin@ipaserver]$ ipa group-add-member sudoers --users=tuser1
[admin@ipaserver]$ ipa sudorule-add --hostcat=all --cmdcat=all sudoers
[admin@ipaserver]$ ipa sudorule-add-user --group=sudoers sudoers

I should also note I still have the HBAC allow_all rule enabled. If you’ve disabled this then you’ll need to grant sudo rights to the users you want to be able to execute it.

Before starting real testing, I created /etc/sudo.conf with these contents:

Debug sudo /var/log/sudo.log all@debug

This gives me a quite verbose log of what is going on. It probably makes more sense to a sudo developer but I can more or less follow along with the number of rules being evaluated, etc.

To double-check that the rule exists we can look in it in LDAP as the IPA admin user:

[admin@ipaserver]$ kinit admin
[admin@ipaserver]$ ldapsearch -LLL -Y GSSAPI -b ou=SUDOers,dc=example,dc=com
SASL/GSSAPI authentication started
SASL username: admin@EXAMPLE.COM
SASL SSF: 56
SASL data security layer installed.
dn: ou=sudoers,dc=example,dc=com
objectClass: extensibleObject
ou: sudoers

dn: cn=sudoers,ou=sudoers,dc=example,dc=com
objectClass: sudoRole
objectClass: top
sudoUser: %sudoers
sudoHost: ALL
sudoCommand: ALL
cn: sudoers

Ok, so now I just need to ssh into this box and try sudo -l

[admin@ipaserver]$ ssh tuser1@ipaserver
[tuser1@ipaserver]$ sudo -l
[sudo] password for tuser1: 
User tuser1 may run the following commands on ipaserver:
    (root) ALL

I also want to avoid authentication so I can update the rule to not require it:

[admin@ipaserver]$ ipa sudorule-add-option sudoers --sudooption='!authenticate'

Remember that the rules are cached so changes may not be available immediately, but it worked for me:

[tuser1@ipaserver]$ sudo -l
User tuser1 may run the following commands on ipaserver:
    (root) ALL

A somewhat old, but good, document to read is http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf. In particular it has good information how the caching works.

FreeIPA and no DNA range

Ok, so let’s say you have an initial IPA master and one more more additional masters (aka replicas). You’ve always done all administration on the first one and it is now temporarily or permanently gone, but it’s gone, and you really need to add that new CEO’s unix account.

If you try to add a new user you might  get a nasty error like this:

ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed.

When a master is created it isn’t automatically assigned a DNA range for POSIX IDs. A range is requested from the master it was created from when a range is needed. It gets half the remaining range on the master it talks to.

This means that the current master can’t contact another one to get a DNA range, so you can’t add any new users.

You can find the master it is trying to talk to here:

$ ldapsearch -x -D 'cn=Directory Manager' -W -b cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=example,dc=com

In all likelihood it is pointing to the master that is down.

So how do you fix it?

If you have another master with a DNA range assigned then you can change the value of dnaHostname in the above entry to point to that master. The downside is that you run the risk of losing a huge chunk of unused IDs.

How do I do it without losing a ton of values? That’s quite a loaded question as it depends greatly on your environment. What you want to avoid, at almost all costs is to end up with an overlapping DNA configuration such that two masters are issuing UIDs from the same namespace, or to configure it such that it is re-assigning values.

You can find the initial namespace with:

$ ipa idrange-find

---------------
1 range matched
---------------
Range name: EXAMPLE.COM_id_range
First Posix ID of the range: 1689600000
Number of IDs in the range: 200000
Range type: local domain range
----------------------------
Number of entries returned 1
----------------------------

Or by looking at /var/log/ipaserver-install.log on the initial master.

DNA would have tried to give you half its remaining range if the master had been up so for safety you could try that, assuming it doesn’t overlap any other masters. You’ll need to check their DNA configurations to be sure.

If you are running IPA 3.3+ then ipa-replica-manage can help you configure DNA properly. See dnarange-show and dnarange-set. Don’t be confused by dnanextrange-*, that is more for preserving ranges when a master is deleted.

For now I’m doing this the manual way which will work on any version.

Run this on each master:

$ ldapsearch -x -D 'cn=Directory Manager' -W -b 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config'

If the dnaNextValue is 1101 and the dnaMaxValue is 1100 then no range has yet been assigned.

WARNING: You cannot currently use the ipa idrange-add command to add a new range for POSIX uids. Through IPA 4.1 there is no connection between DNA and the ID range. The ID range shown with the idrange command is a convenience only.

Once you’re sure you have a viable range you can update the non-working master with whatever range you’ve come up with:

$ ldapmodify -x -D 'cn=Directory Manager' -W
Enter LDAP Password:
dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config
changetype: modify
replace: dnaNextValue
dnaNextValue: 1689700000
-
replace: dnaMaxValue
dnaMaxValue: 1689799999
^D

modifying entry "cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config"

Now you can add a new user successfully:

$ ipa user-add --first=tim --last=user tuser1
-------------------
Added user "tuser1"
-------------------
  User login: tuser1
  First name: tim
  Last name: user
  Full name: tim user
  Display name: tim user
  Initials: tu
  Home directory: /home/tuser1
  GECOS: tim user
  Login shell: /bin/sh
  Kerberos principal: tuser1@EXAMPLE.COM
  Email address: tuser1@example.com
  UID: 1689700000
  GID: 1689700000
  Password: False
  Member of groups: ipausers
  Kerberos keys available: False

You can see that the UID is the value of dnaNextValue we set.