<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
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.<br>
<br>
The support-3.3 branch is fairly stable as MidPoint 3.3.1 release
is planned to happen in a couple of weeks.<br>
<br>
<pre class="moz-signature" cols="72">--
Radovan Semancik
Software Architect
evolveum.com
</pre>
<br>
<br>
On 03/01/2016 06:04 PM, Ivan Noris wrote:<br>
</div>
<blockquote cite="mid:56D5CB88.8090504@evolveum.com" type="cite">
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
Hi Shawn,<br>
<br>
I've been configuring posixAccount and posixGroup configuration
for both OpenDJ and OpenLDAP.<br>
<br>
Please refer to samples in
midpoint/testing/story/src/test/resources/unix, especially:<br>
1) resource definition: resource-opendj.xml (for OpenLDAP it's
mostly the same but you can compare with your current resource)<br>
2) role definition: role-unix.xml<br>
<br>
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:<br>
<br>
<inducement><br>
<construction><br>
<!-- OpenDJ resource --><br>
<resourceRef
oid="10000000-0000-0000-0000-000000000003"
type="c:ResourceType"/><br>
<kind>account</kind><br>
</construction><br>
</inducement><br>
<br>
This constructs standard inetOrgPerson account in LDAP.<br>
<br>
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:<br>
<br>
<inducement><br>
<construction><br>
<!-- OpenDJ resource --><br>
<resourceRef
oid="10000000-0000-0000-0000-000000000003"
type="c:ResourceType"/><br>
<kind>account</kind><br>
<b>
<auxiliaryObjectClass>ri:posixAccount</auxiliaryObjectClass></b><b><br>
</b><b> </b> <attribute><br>
<ref>ri:uidNumber</ref><br>
<outbound><br>
<strength>strong</strength><br>
<source><br>
<path>extension/uidNumber</path><br>
</source><br>
</outbound><br>
</attribute><br>
<attribute><br>
<ref>ri:gidNumber</ref><br>
<outbound><br>
<strength>strong</strength><br>
<source><br>
<path>extension/uidNumber</path><br>
</source><br>
</outbound><br>
</attribute><br>
<attribute><br>
<ref>ri:homeDirectory</ref><br>
<outbound><br>
<strength>strong</strength><br>
<source><br>
<path>name</path><br>
</source><br>
<expression><br>
<script><br>
<code>'/home/' +
name</code><br>
</script><br>
</expression><br>
</outbound><br>
</attribute><br>
<attribute><br>
<ref>ri:homeDirectory</ref><br>
<outbound><br>
<strength>strong</strength><br>
<source><br>
<path>name</path><br>
</source><br>
<expression><br>
<script><br>
<code>'/home/' +
name</code><br>
</script><br>
</expression><br>
</outbound><br>
</attribute><br>
</construction><br>
</inducement><br>
<br>
<inducement><br>
<focusMappings><br>
<mapping><br>
<name>sequenceUID</name><br>
<strength>weak</strength><br>
<expression><br>
<sequentialValue><br>
<sequenceRef
oid="7d4acb8c-65e3-11e5-9ef4-6382ba96fe6c"/><br>
</sequentialValue><br>
</expression><br>
<target><br>
<path>extension/uidNumber</path><br>
</target><br>
</mapping><br>
</focusMappings><br>
</inducement><br>
<br>
Assignment of this role causes the LDAP account to be<b> extended</b>
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.<br>
<br>
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.<br>
<br>
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".<br>
<br>
Regards,<br>
Ivan<br>
<br>
<br>
<div class="moz-cite-prefix">On 03/01/2016 04:12 PM, Shawn
McKinney wrote:<br>
</div>
<blockquote
cite="mid:461AC5E7-F537-4768-97A0-0B834DD756D3@symas.com"
type="cite">
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Ing. Ivan Noris
Senior Identity Management Engineer & IDM Architect
evolveum.com evolveum.com/blog/
___________________________________________________
"Semper ID(e)M Vix."
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
midPoint mailing list
<a class="moz-txt-link-abbreviated" href="mailto:midPoint@lists.evolveum.com">midPoint@lists.evolveum.com</a>
<a class="moz-txt-link-freetext" href="http://lists.evolveum.com/mailman/listinfo/midpoint">http://lists.evolveum.com/mailman/listinfo/midpoint</a>
</pre>
</blockquote>
<br>
<br>
</body>
</html>