[midPoint] Active Directory and custom attributes & auxiliary objectclass
Pavol Mederly
mederly at evolveum.com
Thu Jul 9 07:59:43 CEST 2015
Jason, Anton,
thank you for samples & suggestions for the wiki article. I hope I'll be
able to update it soon.
Anton, have you succeeded in solving your problem? If not, how urgent is
it for you?
Pavol
> Sorry, that bshpSchema was a little outdatedm wrong display order/names
>
> On Tue, Jul 7, 2015 at 12:11 PM, Jason Everling <jeverling at bshp.edu
> <mailto:jeverling at bshp.edu>> wrote:
>
> Yes, it is defined against account. I did not modify anything in
> midPoint. All I did was reference those attributes in an
> objectTemplate during user creation and modification.
>
> I added our files along with our AD resource header below
>
> schema.xml is in the root on the connector server so c:\program
> files (x86)\Identity Connectors\Connector Server\ and
> bshpSchema.xsd is in midpoint.home location /schema folder.
>
> Sampled from top, the blue is what you would need to add then
> reference that in templates and resource
>
> <objects
> xmlns="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:q="http://prism.evolveum.com/xml/ns/public/query-3"
>
> xmlns:c="http://midpoint.evolveum.com/xml/ns/public/common/common-3"
>
> xmlns:mr="http://prism.evolveum.com/xml/ns/public/matching-rule-3"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
>
> xmlns:ri="http://midpoint.evolveum.com/xml/ns/public/resource/instance-3"
>
> xmlns:icfc="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/connector-schema-3"
>
> xmlns:icfs="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/resource-schema-3"
> xmlns:bshp="http://idm.test.local/xml/ns/public/testdomain"
>
> xsi:schemaLocation="http://midpoint.evolveum.com/xml/ns/public/common/common-3
> ../../infra/schema/src/main/resources/xml/ns/public/common/common-3.xsd">
>
> <icfc:configurationProperties
>
> xmlns:icfcad="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/ActiveDirectory.Connector/Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector"
>
> xmlns:ex="http://midpoint.evolveum.com/xml/ns/public/connector/icf-1/bundle/ActiveDirectory.Connector/Org.IdentityConnectors.ActiveDirectory.ActiveDirectoryConnector">
> <icfcad:DirectoryAdminName>USER</icfcad:DirectoryAdminName>
> <icfcad:DirectoryAdminPassword>
> <clearValue>PASSWORD</clearValue>
> </icfcad:DirectoryAdminPassword>
> <icfcad:ObjectClass>User</icfcad:ObjectClass>
> <icfcad:Container>dc=TEST,dc=LOCAL</icfcad:Container>
> <icfcad:CreateHomeDirectory>false</icfcad:CreateHomeDirectory>
> <icfcad:LDAPHostName>DC1.TEST.LOCAL</icfcad:LDAPHostName>
> <icfcad:SearchChildDomains>false</icfcad:SearchChildDomains>
> <icfcad:DomainName>TEST.LOCAL</icfcad:DomainName>
> <icfcad:SyncGlobalCatalogServer>DC1.TEST.LOCAL</icfcad:SyncGlobalCatalogServer>
> <icfcad:SyncDomainController>DC1.TEST.LOCAL</icfcad:SyncDomainController>
> <!-- Extend Schema (reference to file on Domain
> Controller) -->
> <ex:ObjectClassesExtensionFile>schema.xml</ex:ObjectClassesExtensionFile>
> </icfc:configurationProperties>
>
> Then in objectTemplate mappings or resource mappings define each
> attribute
>
> <attribute>
> <ref>ri:eduPersonAffiliation</ref>
> <outbound>
> <source>
> <path>
> declare namespace
> bshp="http://idm.test.local/xml/ns/public/testdomain";
> $c:user/c:extension/bshp:eduPersonAffiliation
> </path>
> </source>
> </outbound>
> <inbound>
> <target>
> <path>
> declare namespace
> bshp="http://idm.test.local/xml/ns/public/testdomain";
> $c:user/c:extension/bshp:eduPersonAffiliation
> </path>
> </target>
> </inbound>
> </attribute>
>
> JASON
>
> On Tue, Jul 7, 2015 at 9:13 AM, <midpoint at mybtinternet.com
> <mailto:midpoint at mybtinternet.com>> wrote:
>
> Hi,
>
> I second this ... and did the same.
>
> Regards,
> Anton
>
> ----Original message----
> From : jeverling at bshp.edu <mailto:jeverling at bshp.edu>
> Date : 06/07/2015 - 17:26 (BST)
>
> To : midpoint at lists.evolveum.com
> <mailto:midpoint at lists.evolveum.com>
> Subject : Re: [midPoint] Active Directory and custom
> attributes & auxiliary objectclass
>
> There is also some parts that should be added to that wiki
> page,
>
> After creating the schema.xml and adding to your server
> with the Connector Server running you have to create an
> extension file for midpoint to match that one and place in
> midpoint.home schema like these
> (https://github.com/Evolveum/midpoint/tree/master/samples/schema)
> so that midPoint can read/write to those new objectClass
> attributes.
>
> After those are added you have to add a new declaration to
> your resource xml like so
>
> xmlns:my="http://myself.me/schemas/whatever"
>
> Then after you have to use that in each custom attribute
> mapping like so
> <attribute> <ref>ri:customAttribute</ref> <outbound>
> <source> <path> declare namespace
> my="http://myself.me/schemas/whatever";
> $c:user/c:extension/my:customAttribute</path> </source>
> </outbound> <inbound> <target> <path> declare namespace
> my="http://myself.me/schemas/whatever";
> $c:user/c:extension/my:customAttribute</path> </target>
> </inbound> </attribute>
>
> After you add those you can read/write to any attribute
> and also create new users with those new attributes.
>
> When I first setup our AD resource it took me a little
> while after looking at the samples, something like this I
> think should also be added/mentioned to that wiki page
>
> JASON
>
>
> On Mon, Jul 6, 2015 at 11:03 AM, Jason Everling
> <jeverling at bshp.edu <mailto:jeverling at bshp.edu>> wrote:
>
> I am using the AD Connector with additional custom
> auxiliary object classes ( I have 4 additional classes
> ) and it works fine when I create new users in the GUI
> or from any other resource and is correctly created in
> AD.
>
> My Object Classes managed in midPoint using the
> extension functionality
>
> bshpGroup
> bshpOrg
> bshpPerson
> eduPerson
>
> All of the above in AD Schema are Class Type:
> Auxiliary with Parent "top"
>
> Is this not the same?
>
> JASON
>
> On Mon, Jul 6, 2015 at 9:05 AM, Pavol Mederly
> <mederly at evolveum.com <mailto:mederly at evolveum.com>>
> wrote:
>
> Hello Anton,
>
> now I perhaps understand your situation a little
> bit better. Because what I was used to see was
> that people extended the "basic" AD user object
> with custom attributes, without introducing
> separate objectClasses. Neither did I; and
> although I've seen that you had mentioned using
> auxiliary object classes, I have no experiences
> with them in Active Directory.
>
>> I was hoping it is possible to override the
>> objectClasses in the schema handling, but
>> can't find an example.
> If you mean adding auxiliary object classes, then
> a sample is e.g. in
> testing\story\src\test\resources\unix\resource-opendj.xml
> <https://github.com/Evolveum/midpoint/blob/master/testing/story/src/test/resources/unix/resource-opendj.xml>
> file. However, unfortunately, this is a feature of
> new LDAP connector. The ActiveDirectory connector
> does not support auxiliary object classes yet.
>
>> The other option, I guess, would be to use the
>> the custom
>> schema feature of ObjectClassesExtensionFile, but
>> I have a few questions on this:
>> 1) Is the objectClass type always Tenant?
> No. The new object class can be anything. "Tenant"
> was an object class that was used in a particular
> customer's setting.
>
>> 2) Does this add an objectClass in addition of
>> the user class or instead of the user class?
> In addition to the user class. The existing
> AccountObjectClass will be left intact. New object
> class will be seen in midPoint as
> Custom*someName*ObjectClass, if the object class
> will be defined as "someName" in the connector.
>
> Unfortunately, the connector will not recognize
> such a class to be an extension of the
> AccountObjectClass and will not apply the standard
> functionality (written in C#) to manage objects of
> this class.
>
> So, if you would like to use it to manage your
> users, you would need either
> 1) to implement everything in PowerShell, which is
> quite a lot of work (given that you would have to
> implement e.g. exception handling, and so on),
> 2) or to do some hacking with custom scripts, like
> calling original AD connector to do its part of
> the work and then manage specific attributes using
> PowerShell.
>
> Neither of this seems to me a "clean solution".
>
> Overall, we plan to enhance Active Directory
> connector with some of the new features Radovan
> has recently implemented for LDAP one. Auxiliary
> object class support is among them. But I cannot
> say when that would be done. Maybe you could
> contact Igor Farinic for options there.
>
>> 3) How / when are the custom scripts called?
> Custom scripts feature is currently only available
> in Exchange connector, which is a superset of AD
> connector useful mainly if you want to manage also
> Exchange objects. (But I think nothing precludes
> the use of it in AD-only settings; I hope it no
> longer depends on the existence of specific
> Exchange run time libraries.) These scripts are
> called before, after and/or instead of "main" C#
> code. They can be configured with regards to
> object class and operation. E.g. you can define a
> "Before" script for each "Create" operation for
> "AddressBookList" object class. Or, if you have a
> custom object class, you have to define all the
> operations as PowerShell custom scripts.
>
> This is an example of definition of a custom script:
>
> <?xml version="1.0"?>
> <ScriptingInfo>
>
> <OperationInfo>
> <Type>Create</Type>
> <AfterMain>
> <ObjectType>OfflineAddressBook</ObjectType>
> <File>after-create-OAB.ps1</File>
> </AfterMain>
> </OperationInfo>
>
> </ScriptingInfo>
>
> It says that after executing main C# routine for
> Create operation for OfflineAddressBook object,
> the after-create-OAB.ps1 file (stored in the
> ConnectorServer directory) will be executed.
> Such a script can expect one parameter, called
> "ctx" (context), pointing to the following data
> structure:
>
> public class Context {
> public Connector Connector { get; set; }
> public ActiveDirectoryConfiguration
> ConnectorConfiguration { get; set; }
> public string OperationName { get; set; }
> public Scripting.Position Position { get; set; }
> public ObjectClass ObjectClass { get; set; }
> }
>
> (There are specific contexts for individual
> operations, see
> https://github.com/Evolveum/openicf/blob/master/connectors/dotnet/ActiveDirectoryConnector/Scripting.cs
>> 4) Is there examples on how to use the custom
>> schema feature?
> Well, the documentation of these new features is
> still in its beginnings. I'm afraid the wiki
> article I mentioned is the only piece available :(
> Maybe someone on this list could provide some
> examples...
>
> Overall, the most clean way (as I currently see
> it) is to add support for auxiliary object classes
> to the standard AD/Exchange connector.
>
> Best regards,
> Pavol
>
>
>
> On 6. 7. 2015 14:51, ANTON OPPERMAN wrote:
>> Thx Pavol! That is getting me very close ...
>>
>> Took a while to figure out just how to do it; the
>> documentation can be clearer; e.g. where
>> the value of ObjectClassesExtensionFile is set
>> and which system it should be stored on. I
>> saw a ref in the UI that seemed to allow for
>> this, but this didn't work for me.
>>
>> I have defined my custom schema entries in the
>> AccountObjectClass section and can
>> retrieve and set values if my auxiliary
>> objectClass is present on the user. Obviously
>> creating an account with schema extension fails
>> as newly created users will not have
>> the auxiliary objectClass (yet).
>>
>> I was hoping it is possible to override the
>> objectClasses in the schema handling, but
>> can't find an example. The other option, I guess,
>> would be to use the the custom
>> schema feature of ObjectClassesExtensionFile, but
>> I have a few questions on this:
>> 1) Is the objectClass type always Tenant?
>> 2) Does this add an objectClass in addition of
>> the user class or instead of the user class?
>> 3) How / when are the custom scripts called?
>> 4) Is there examples on how to use the custom
>> schema feature?
>>
>> Thx!
>>
>> Regards,
>> Anton
>>
>>
>> ----Original message----
>> From : mederly at evolveum.com
>> <mailto:mederly at evolveum.com>
>> Date : 02/07/2015 - 15:17 (BST)
>> To : midpoint at lists.evolveum.com
>> <mailto:midpoint at lists.evolveum.com>
>> Subject : Re: [midPoint] Active Directory and
>> custom attributes & auxiliary objectclass
>>
>> Hello Anton,
>>
>> the AD connector schema can now be extended
>> via configuration. Please see
>> https://wiki.evolveum.com/display/midPoint/Extending+AD+and+Exchange+Connector+Schema+HOWTO
>> for a simple HOWTO.
>>
>> However, contrary to what's written there, I
>> would recommend using the latest versions of
>> AD/Exchange connector and ConnId:
>> - Exchange Connector: 1.4.1.20283
>> (https://wiki.evolveum.com/display/midPoint/Exchange+Connector)
>> - Connector Server: 1.4.0.84
>> (https://wiki.evolveum.com/display/midPoint/.NET+Connector+Server)
>>
>> Also please note that auxiliary object
>> classes are not supported for AD. What you
>> need to do is to extend the basic
>> AccountObjectClass (or object class for
>> group/OU) with your custom attributes.
>>
>> Best regards,
>> Pavol
>>
>> On 2. 7. 2015 16:10,
>> midpoint at mybtinternet.com
>> <mailto:midpoint at mybtinternet.com> wrote:
>>> Hi,
>>>
>>> We intend managing a number of different
>>> directories with similar data but for
>>> populations of users that
>>> must be stored separately. We also have a
>>> fairly extensive number of custom attributes
>>> grouped in an
>>> auxiliary objectClass.
>>>
>>> For OpenDJ, I was able to setup the
>>> resources and am able to manage all the
>>> custom attributes; e.g.
>>> the connector allows definition of which
>>> classes to use.
>>>
>>> Now trying to replicate with AD and have
>>> basic AD provisioning working; however, I
>>> don't see similar
>>> options for defining additional
>>> objectClasses to use. Have looked in Jira;
>>> all references suggest modifying
>>> objectClasses.xml and building a custom
>>> instance of the connector. I don't see how
>>> the custom
>>> objectClass is referenced. Have I missed
>>> something?
>>>
>>> As for building a custom instance of the
>>> connector; I would prefer not to do that as:
>>> 1) we could run into issues that are related
>>> to our attempt of implementing
>>> 2) each time there is a new fix, we
>>> would need to go and retro-fit and rebuild
>>> 3) each time we extend the schema, we
>>> need to go and ammend and rebuild
>>>
>>> While I may be able to build a custom
>>> instance, once this is handed-over to
>>> business-as-usual, they
>>> most certainly will not have the skills to
>>> support this.
>>>
>>> Is this still the process to follow at
>>> this time, or has this changed? If not
>>> changed, is there a plan to
>>> make the AD adapter configurable ito
>>> custom schema (like OpenDJ)? Time-frame?
>>>
>>> Thx
>>>
>>> Regards,
>>> Anton
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> midPoint mailing list
>>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>>> http://lists.evolveum.com/mailman/listinfo/midpoint
>>
>>
>>
>>
>>
>> _______________________________________________
>> midPoint mailing list
>> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
>> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com
> <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> --
> JASON
>
>
>
>
> --
> JASON
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary
> and confidential; intended for only the recipient(s) named
> above and may contain information that is privileged. You
> should not retain, copy or use this e-mail or any
> attachments for any purpose, or disclose all or any part
> of the contents to any person. Any views or opinions
> expressed in this e-mail are those of the author and do
> not represent those of the Baptist School of Health
> Professions. If you have received this e-mail in error, or
> are not the named recipient(s), you are hereby notified
> that any review, dissemination, distribution or copying of
> this communication is prohibited by the sender and to do
> so might constitute a violation of the Electronic
> Communications Privacy Act, 18 U.S.C. section 2510-2521.
> Please immediately notify the sender and delete this
> e-mail and any attachments from your computer.
>
>
>
> _______________________________________________
> midPoint mailing list
> midPoint at lists.evolveum.com <mailto:midPoint at lists.evolveum.com>
> http://lists.evolveum.com/mailman/listinfo/midpoint
>
>
>
>
> --
> JASON
>
>
>
>
> --
> JASON
>
>
>
> CONFIDENTIALITY NOTICE:
> This e-mail together with any attachments is proprietary and
> confidential; intended for only the recipient(s) named above and may
> contain information that is privileged. You should not retain, copy or
> use this e-mail or any attachments for any purpose, or disclose all or
> any part of the contents to any person. Any views or opinions
> expressed in this e-mail are those of the author and do not represent
> those of the Baptist School of Health Professions. If you have
> received this e-mail in error, or are not the named recipient(s), you
> are hereby notified that any review, dissemination, distribution or
> copying of this communication is prohibited by the sender and to do so
> might constitute a violation of the Electronic Communications Privacy
> Act, 18 U.S.C. section 2510-2521. Please immediately notify the sender
> and delete this e-mail and any attachments from your computer.
>
>
> _______________________________________________
> 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/20150709/006e6084/attachment.htm>
More information about the midPoint
mailing list