Care and feeding of your FreeIPA / RH IDM deployment

System accounts or service accounts – accounts that a service can use for binding to the directory and performing a specific task or set of tasks – live in a special container:¹

cn=sysaccounts,cn=etc,$SUFFIX

You might want one of these if, say, for instance, you have a service which wants to be able to read users OTP keys, piggybacking on the very nice self-management interface for these.

Create a system account² using the standard LDAP tools:

# kinit admin
# ldapadd -Y gssapi <<EOF
dn: uid=otpbuddy,cn=sysaccounts,cn=etc,$SUFFIX
changetype: add
objectclass: account
objectclass: simplesecurityobject
uid: otpbuddy
userPassword: thepassword
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0

EOF

Note the passwordExpirationTime, which allegedly has to be there due to some IPA principle of making the password insta-expire if not set by the user itself.

Now, assuming that you have a privilege named Read OTP fields³, and which should be granted the service account:

# cat >apply_privilege.ldif <<EOF
dn: cn=Read OTP fields,cn=privileges,cn=pbac,$SUFFIX
add:member:uid=otpbuddy,cn=sysaccounts,cn=etc,$SUFFIX
EOF

# ipa-ldap-updater apply_privilege.ldif
The ipa-ldap-updater command was successful

Note that these changes will not be reflected in the web interface. We're colouring slightly outside the lines here, but not too much.⁴ The grantees of the privilege can be discovered by LDAP commands, or through the IPA interfaces with the following command:

# ipa privilege-show 'Read OTP fields' --raw
cn: Read OTP fields
member: uid=otpbuddy,cn=sysaccounts,cn=etc,$SUFFIX