Bug 1020957 - IPA throws attribute error when trying to add a new default objectclass
IPA throws attribute error when trying to add a new default objectclass
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ipa (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Martin Kosek
Namita Soman
Depends On:
  Show dependency treegraph
Reported: 2013-10-18 11:21 EDT by Pete Savage
Modified: 2014-11-17 07:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-11-04 05:59:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Pete Savage 2013-10-18 11:21:55 EDT
Description of problem:
When trying to add a new objectclass to the default set of userclasses, IPA responds with an error on both the CLI and UI interfaces

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Log into web UI 
2. Goto IPA Server -> Configuration
3. Try to add 'pilotobject' to the list of userobjects

Actual results:
Fails with IPA error 
ERROR: attribute "ipaKrbAuthzData" not allowed

Expected results:
ObjectClass should be added

Additional info:
[root@ipa-server ~]# /usr/bin/ipa config-mod --userobjectclasses=top,person,organizationalperson,inetorgperson,inetuser,posixaccount,krbprincipalaux,krbticketpolicyaux,ipaobject,ipasshuser,pilotobject
ipa: ERROR: attribute "ipaKrbAuthzData" not allowed
Comment 1 Alexander Bokovoy 2013-10-18 11:26:17 EDT
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.
Comment 3 Martin Kosek 2013-10-21 11:02:30 EDT
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?
Comment 4 Pete Savage 2013-10-21 12:07:22 EDT
Hi Martin,

SASL/GSSAPI authentication started
SASL username: admin@$IPA_FQDN
SASL data security layer installed.
objectClasses: ( 2.16.840.1.113730. 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. NAME 'ipaConfigObject' DESC 'gener
 ic config object for IPA' AUXILIARY MAY ipaConfigString X-ORIGIN 'IPA v2' )

This was a fresh install.
Comment 5 Martin Kosek 2013-10-22 06:29:30 EDT
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.
Comment 7 Martin Kosek 2013-10-25 05:18:15 EDT
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.
Comment 8 Martin Kosek 2013-10-25 07:08:24 EDT
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.
Comment 9 Martin Kosek 2013-11-04 05:59:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.