[midPoint] Adding new posixaccount attributes
Radovan Semancik
radovan.semancik at evolveum.com
Tue Mar 1 18:35:42 CET 2016
Hi,
I have one more advice: switch to midPoint 3.3.1-SNAPSHOT if you can.
You can get that by compiling the sources from the support-3.3 branch.
We have already identified a handful of bugs related to handling of
auxiliary object classes in midPoint 3.3. These are fixed in
3.3.1-SNAPSHOT. And I'm currently fixing another one.
The support-3.3 branch is fairly stable as MidPoint 3.3.1 release is
planned to happen in a couple of weeks.
--
Radovan Semancik
Software Architect
evolveum.com
On 03/01/2016 06:04 PM, Ivan Noris wrote:
> Hi Shawn,
>
> I've been configuring posixAccount and posixGroup configuration for
> both OpenDJ and OpenLDAP.
>
> Please refer to samples in
> midpoint/testing/story/src/test/resources/unix, especially:
> 1) resource definition: resource-opendj.xml (for OpenLDAP it's mostly
> the same but you can compare with your current resource)
> 2) role definition: role-unix.xml
>
> To create standard LDAP account, you would (assuming the unix story
> tests) assign "Basic user" role contained in the file role-basic.xml.
> Which has:
>
> <inducement>
> <construction>
> <!-- OpenDJ resource -->
> <resourceRef
> oid="10000000-0000-0000-0000-000000000003" type="c:ResourceType"/>
> <kind>account</kind>
> </construction>
> </inducement>
>
> This constructs standard inetOrgPerson account in LDAP.
>
> To extend the account to use auxiliary object class posixAccount, you
> would (assuming the unix story tests) assign "Unix user" role
> contained in the file "role-unix.xml". Which has:
>
> <inducement>
> <construction>
> <!-- OpenDJ resource -->
> <resourceRef
> oid="10000000-0000-0000-0000-000000000003" type="c:ResourceType"/>
> <kind>account</kind>
> *<auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>**
> *** <attribute>
> <ref>ri:uidNumber</ref>
> <outbound>
> <strength>strong</strength>
> <source>
> <path>extension/uidNumber</path>
> </source>
> </outbound>
> </attribute>
> <attribute>
> <ref>ri:gidNumber</ref>
> <outbound>
> <strength>strong</strength>
> <source>
> <path>extension/uidNumber</path>
> </source>
> </outbound>
> </attribute>
> <attribute>
> <ref>ri:homeDirectory</ref>
> <outbound>
> <strength>strong</strength>
> <source>
> <path>name</path>
> </source>
> <expression>
> <script>
> <code>'/home/' + name</code>
> </script>
> </expression>
> </outbound>
> </attribute>
> <attribute>
> <ref>ri:homeDirectory</ref>
> <outbound>
> <strength>strong</strength>
> <source>
> <path>name</path>
> </source>
> <expression>
> <script>
> <code>'/home/' + name</code>
> </script>
> </expression>
> </outbound>
> </attribute>
> </construction>
> </inducement>
>
> <inducement>
> <focusMappings>
> <mapping>
> <name>sequenceUID</name>
> <strength>weak</strength>
> <expression>
> <sequentialValue>
> <sequenceRef
> oid="7d4acb8c-65e3-11e5-9ef4-6382ba96fe6c"/>
> </sequentialValue>
> </expression>
> <target>
> <path>extension/uidNumber</path>
> </target>
> </mapping>
> </focusMappings>
> </inducement>
>
> Assignment of this role causes the LDAP account to be*extended* with
> posixAccount aux. object class and the additional mappings define the
> mandatory posixAccount attributes. As uidNumber is required, it will
> be generated using the focusMapping with sequence object (simple
> iterator), stored in user's extension attribute uidNumber and
> provisioned to LDAP's attribute uidNumber and gidNumber right away.
>
> By unassigning the "Unix User" role, posixAccount aux. object class is
> removed from the account and standard inetOrgPerson remains. So you
> can have LDAP accounts both with and without posixAccount attributes
> and you can safely switch between them just by assigning/unassigning
> Unix user role.
>
> All the required objects are present in that directory, they're used
> for automatic story testing in midPoint. We're extending the tests
> literally "as we speak".
>
> Regards,
> Ivan
>
>
> On 03/01/2016 04:12 PM, Shawn McKinney wrote:
>> Hello,
>>
>> We are using midpoint 3.3 and this ldap connector (latest as of a couple of week ago):
>>
>> <name>ICF com.evolveum.polygon.connector.ldap.LdapConnector v1.4.3.0-SNAPSHOT</name>
>>
>> The current task, is to manage rfc2307bis posixAccount attributes from within the midpoint console. These attributes correspond with an auxiliary object class in the LDAP entry.
>>
>> The resource schema definition excerpt can be found below. Not the entire definition but enough to show you how we’re handling the aux object class posixAccount.
>>
>> I’ve also extended the midpoint schema xsd file so the new attributes will show up in the console.
>>
>> Everything works fine when operating on ldap objects that already have existing the posixAccount aux objectClass attribute (i.e. prepopulated from the start). But when I try to add the attributes to an ldap entry that has not already been prepopulated with aux objectClass (and corresponding must have attributes) I get this error:
>>
>> "Schema violation during processing shadow: shadow: uid=foo2,ou=People,dc=example,dc=com (OID:afc71094-be90-40eb-9df9-da939145c65c): Schema violation: Invalid attribute: org.identityconnectors.framework.common.exceptions.InvalidAttributeValueException(Error modifying entry uid=foo2,ou=People,dc=example,dc=com: attribute 'uidNumber' not allowed)->org.apache.directory.api.ldap.model.exception.LdapSchemaViolationException(attribute 'uidNumber' not allowed)”
>>
>> The error tells us midpoint is attempting to add these attributes without including the attribute for the aux object class itself:
>>
>> objectClass: posixAccount
>>
>> Without this attribute being included in the add operation of course it will fail. My question, how do I compel the midpoint operation to include the necessary object class attribute when newly populating ldap objects?
>>
>> Thanks in advance for your help,
>>
>> Shawn
>>
>>
>> ** Begin schema reference ***
>>
>> <schemaHandling>
>> <objectType>
>> <kind>account</kind>
>> <displayName>Normal Account</displayName>
>> <default>true</default>
>> <objectClass>ri:inetOrgPerson</objectClass>
>> <auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass>
>>
>> <attribute>
>> <c:ref>ri:homeDirectory</c:ref>
>> <displayName>Home Directory</displayName>
>> <limitations>
>> <maxOccurs>1</maxOccurs>
>> </limitations>
>> <outbound>
>> <source>
>> <path>$user/extension/homeDirectory</path>
>> </source>
>> </outbound>
>> <inbound>
>> <target>
>> <path>$user/extension/homeDirectory</path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> <attribute>
>> <c:ref>ri:loginShell</c:ref>
>> <displayName>Login Shell</displayName>
>> <limitations>
>> <maxOccurs>1</maxOccurs>
>> </limitations>
>> <outbound>
>> <source>
>> <path>$user/extension/loginShell</path>
>> </source>
>> </outbound>
>> <inbound>
>> <target>
>> <path>$user/extension/loginShell</path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> <attribute>
>> <c:ref>ri:gecos</c:ref>
>> <displayName>Gecos</displayName>
>> <limitations>
>> <maxOccurs>1</maxOccurs>
>> </limitations>
>> <outbound>
>> <source>
>> <path>$user/extension/gecos</path>
>> </source>
>> </outbound>
>> <inbound>
>> <target>
>> <path>$user/extension/gecos</path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> <attribute>
>> <c:ref>ri:uidNumber</c:ref>
>> <displayName>UserId Number</displayName>
>> <limitations>
>> <maxOccurs>1</maxOccurs>
>> </limitations>
>> <outbound>
>> <source>
>> <path>$user/extension/uidNumber</path>
>> </source>
>> </outbound>
>> <inbound>
>> <target>
>> <path>$user/extension/uidNumber</path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> <attribute>
>> <c:ref>ri:gidNumber</c:ref>
>> <displayName>GroupId Number</displayName>
>> <limitations>
>> <maxOccurs>1</maxOccurs>
>> </limitations>
>> <outbound>
>> <source>
>> <path>$user/extension/gidNumber</path>
>> </source>
>> </outbound>
>> <inbound>
>> <target>
>> <path>$user/extension/gidNumber</path>
>> </target>
>> </inbound>
>> </attribute>
>>
>> ….
>>
>> ** End schema reference ***
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
> --
> Ing. Ivan Noris
> Senior Identity Management Engineer & IDM Architect
> evolveum.com evolveum.com/blog/
> ___________________________________________________
> "Semper ID(e)M Vix."
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> http://lists.evolveum.com/mailman/listinfo/midpoint
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.evolveum.com/pipermail/midpoint/attachments/20160301/7837b768/attachment.htm>
More information about the midPoint
mailing list