I've tracked this down to the fact that ipaKrbAuthzData attribute is not in any of object classes we use for cn=ipaConfig,cn=etc,$SUFFIX. Since the entry is created in the bootstrap template, it is not validated. However, config-mod --userobjectclasses does some operations that cause validation of the schema correctness for the entry and that one fails.

The fix would be to add ipaKrbAuthzData to an object class that could be added to cn=ipaConfig,cn=etc,$SUFFIX, and also write an update plugin that fixes the entry on package updates.

The attributeType is already there, in ipaGuiConfig objectClass. It is being added in install/updates/10-selinuxusermap.update.

Pete, can you please run the following ldapsearch so that we can see why the attribute is not allowed?

$ ldapsearch -h $IPA_FQDN -D "cn=Directory Manager" -W -x -b "cn=schema" objectClasses | grep -A 8 -i ipaguiconfig

On a side note, did you upgrade IPA from some very old version? Or was it a new installation?

Hi Martin,

SASL/GSSAPI authentication started
SASL username: admin@$IPA_FQDN
SASL SSF: 56
SASL data security layer installed.
objectClasses: ( 2.16.840.1.113730.3.8.2.1 NAME 'ipaGuiConfig' AUXILIARY MAY (
  ipaUserSearchFields $ ipaGroupSearchFields $ ipaSearchTimeLimit $ ipaSearchR
 ecordsLimit $ ipaCustomFields $ ipaHomesRootDir $ ipaDefaultLoginShell $ ipaD
 efaultPrimaryGroup $ ipaMaxUsernameLength $ ipaPwdExpAdvNotify $ ipaUserObjec
 tClasses $ ipaGroupObjectClasses $ ipaDefaultEmailDomain $ ipaMigrationEnable
 d $ ipaCertificateSubjectBase $ ipaSELinuxUserMapDefault $ ipaSELinuxUserMapO
 rder ) )
objectClasses: ( 2.16.840.1.113730.3.8.4.13 NAME 'ipaConfigObject' DESC 'gener
 ic config object for IPA' AUXILIARY MAY ipaConfigString X-ORIGIN 'IPA v2' )

This was a fresh install.

That's strange, LDAP update procedure done as a part of IPA installation should have updated the objectClass as is. Were there any errors in ipa-replica-install in that stage?

This issue may be fixed by simply running the LDAP Update step again, with this command

# ipa-ldap-updater --upgrade

run on the IPA server.

I worked with Pete on this Bugzilla. It seemed as an installation issue where LDAP Update was probably not run during an installation as ipaGuiConfig objectclass was not extended by install/updates/10-selinuxusermap.update.

Pete, please provide ipaserver-install.log so that we can double check that. Without the log, it is hard to guess what might have gone wrong. If you do not have the log ready, we would have to close the bug.

Pete provided ipaserver-install.log to me privately. I investigated it and the ipaGuiConfig objectClass was updated, according to the log.

Additionally, ipakrbauthz attribute was added to the config object which could not have worked if the attribute was not allowed:

2013-10-17T11:39:08Z DEBUG Final value after applying updates
2013-10-17T11:39:08Z DEBUG dn: cn=ipaConfig,cn=etc,dc=example,dc=com
2013-10-17T11:39:08Z DEBUG ipadefaultloginshell: /bin/sh
2013-10-17T11:39:08Z DEBUG ipacertificatesubjectbase: O=EXAMPLE.COM
2013-10-17T11:39:08Z DEBUG ipamigrationenabled: FALSE
2013-10-17T11:39:08Z DEBUG cn: ipaConfig
2013-10-17T11:39:08Z DEBUG ipaSELinuxUserMapDefault:
2013-10-17T11:39:08Z DEBUG  unconfined_u:s0-s0:c0.c1023
2013-10-17T11:39:08Z DEBUG ipaUserObjectClasses:
2013-10-17T11:39:08Z DEBUG  top
2013-10-17T11:39:08Z DEBUG  person
2013-10-17T11:39:08Z DEBUG  organizationalperson
2013-10-17T11:39:08Z DEBUG  inetorgperson
2013-10-17T11:39:08Z DEBUG  inetuser
2013-10-17T11:39:08Z DEBUG  posixaccount
2013-10-17T11:39:08Z DEBUG  krbprincipalaux
2013-10-17T11:39:08Z DEBUG  krbticketpolicyaux
2013-10-17T11:39:08Z DEBUG  ipaobject
2013-10-17T11:39:08Z DEBUG  ipasshuser
2013-10-17T11:39:08Z DEBUG ipadefaultprimarygroup: ipausers
2013-10-17T11:39:08Z DEBUG ipapwdexpadvnotify: 4
2013-10-17T11:39:08Z DEBUG objectclass:
2013-10-17T11:39:08Z DEBUG  nsContainer
2013-10-17T11:39:08Z DEBUG  top
2013-10-17T11:39:08Z DEBUG  ipaGuiConfig
2013-10-17T11:39:08Z DEBUG  ipaConfigObject
2013-10-17T11:39:08Z DEBUG ipagroupsearchfields: cn,description
2013-10-17T11:39:08Z DEBUG ipadefaultemaildomain: example.com
2013-10-17T11:39:08Z DEBUG ipahomesrootdir: /home
2013-10-17T11:39:08Z DEBUG ipasearchtimelimit: 2
2013-10-17T11:39:08Z DEBUG ipaKrbAuthzData:
2013-10-17T11:39:08Z DEBUG  MS-PAC
2013-10-17T11:39:08Z DEBUG ipagroupobjectclasses:
2013-10-17T11:39:08Z DEBUG  top
2013-10-17T11:39:08Z DEBUG  groupofnames
2013-10-17T11:39:08Z DEBUG  nestedgroup
2013-10-17T11:39:08Z DEBUG  ipausergroup
2013-10-17T11:39:08Z DEBUG  ipaobject
2013-10-17T11:39:08Z DEBUG ipasearchrecordslimit: 100
2013-10-17T11:39:08Z DEBUG ipaSELinuxUserMapOrder:
2013-10-17T11:39:08Z DEBUG  guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
2013-10-17T11:39:08Z DEBUG ipaconfigstring: AllowNThash
2013-10-17T11:39:08Z DEBUG ipamaxusernamelength: 32
2013-10-17T11:39:08Z DEBUG ipausersearchfields: uid,givenname,sn,telephonenumber,ou,title
2013-10-17T11:39:08Z DEBUG [(0, 'ipakrbauthzdata', ['MS-PAC'])]
2013-10-17T11:39:08Z DEBUG Live 1, updated 1
2013-10-17T11:39:08Z INFO Done

I am thinking that the objectClass would have to been replaced post-install, by some other installation. Maybe a really old replica which would replace the objectClass definition without looking at current value?

Anyway, I am leaving needsinfo? on Pete to try to provide some reproduction scenario which could help us identify what could possibly went wrong. Without reproduction scenario, I would need to close this bug - we can reopen when/if the issue occurs again and we would have a hint about the scenario.

We do not have any reproduction scenario or information that could lead us to the potential issue.

I will therefore close this bug. However, please feel free to reach back and re-open if you find information how to reproduce.