On Sat, 02 Jun 2012, Dale Macartney wrote:

Hash: SHA1

Evening all

What's the recommended method for using service accounts with IPA?

For example, using a piece of software that needs to bind to LDAP (aka
Zimbra, Moodle, Joomla, etc), having a password expiry on that specific
bind user would result in the application constantly needing the
password changed.

I can see that you can modify the default password policy (i personally
don't want to change this as this works for my requirements), and also
have the ability to create additional pw policies if needed.

What's the best method to create a user, however have that password for
the new user that never expires? Am I thinking along the right lines of
using a different pw policy for the service accounts?
A recommended way is to use system accounts. See, for example, how it is
set up for sudo (section 13.4.1):

We have this particular case covered with following sudobind.ldif file
(available in /usr/share/ipa/sudobind.ldif at IPA server):
#SUDO bind user
dn: uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: sudo
userPassword: $RANDOM_PASSWORD
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

As you can see, it has SimpleSecurityObject and Account object classes, and
password is set to expire at the end of Unix time. You'd need to add
also appropriate ACIs to limit what such account could perform against
IPA's LDAP store.

We use this method for passync (AD replication), sudo integration,
and will use it also for cross-realm trusts with AD in FreeIPAv3,
albeit a bit differently (by making a container in sysaccounts to
include all 'AD agents' from IPA servers exposed via CIFS and limiting
what they can do).

A downside is that you don't see these system accounts through IPA UI/CLI,
they are only managed manually.

/ Alexander Bokovoy

Freeipa-users mailing list

Reply via email to