[midPoint] Active Directory and custom attributes & auxiliary objectclass
Pavol Mederly
mederly at evolveum.com
Thu Jul 9 12:25:08 CEST 2015
Anton,
I'm glad to hear that you've worked around the problem. I would like to
add auxiliary object class support to AD connector (MID-2439
<https://jira.evolveum.com/browse/MID-2439>).
> Something else I learned from the examples was the use on the
> namespace ... this was somewhat
> more murky for me before. Is there a good description of their use
> in the docs?
do you mean this one?
declare namespace bshp="http://idm.test.local/xml/ns/public/testdomain";
$c:user/c:extension/bshp:eduPersonAffiliation
Well, since midPoint 3.0 we have been trying to get rid of the need of
specifying explicit namespaces. Currently they are to be used only to
resolve ambiguities, with slight exceptions (see below).
So, the path could be written as
$user/extension/eduPersonAffiliation
as well.
However, not all places in midPoint currently allow to work with no
namespaces. E.g. <ref> element in schemaHandling/attribute or
schemaHandling/association should contain the ri: or icfs: namespace.
This will be fixed in 3.3 I hope. See MID-2191
<https://jira.evolveum.com/browse/MID-2191>.
And also, at many places - almost all except for legacy XPath (not
<path>!) expressions - it is no longer necessary to use "declare
namespace ..." instruction. It is sufficient to declare the namespace in
traditional XML way (xmlns:xyz="...") upstream. So even in the above
example, the bshp: could be declared directly via xmlns:bshp="..." e.g.
in the root XML element.
Best regards,
Pavol
> Hi,
>
> Jason, thank you for the samples. It confirmed that I had indeed
> performed all the steps required.
> This allowed me to read and write custom attributes once the
> auxiliary class was added to the
> user entry.
>
> Something else I learned from the examples was the use on the
> namespace ... this was somewhat
> more murky for me before. Is there a good description of their use
> in the docs?
>
> One thing I did not find however, was how the auxiliary was added to
> the user entry; e.g. the crux
> of my problem. As Pavol suggested, most may have amended the base
> objectClass, or create a
> new person objectClass, and subsequently would not have the issue.
>
> As I am not willing to add new attributes to existing OOTB
> objectClasses, I had to find a different
> solution. Don't like this much either, but later discovered OpenAM
> already did this in our environment,
> but you can set a relationship from the user objectClass to the
> auxiliary objectClass in the AD
> schema. This then allows you to manage the custom attributes without
> the need to explicitly add the
> objectClass to the user entry. For reference, this article describes
> how to do this:
> https://msdn.microsoft.com/en-us/library/bb727064.aspx
>
> Ideally I would like to see proper auxiliary support for AD as with
> OpenDJ, but I can live with the
> solution I have for now.
>
> Regards,
> Anton
>
> ----Original message----
> From : mederly at evolveum.com
> Date : 09/07/2015 - 06:59 (BST)
> To : midpoint at lists.evolveum.com
> Subject : Re: [midPoint] Active Directory and custom attributes &
> auxiliary objectclass
>
> 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
>
>
>
>
>
> _______________________________________________
> 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/b558b002/attachment.htm>
More information about the midPoint
mailing list