[midPoint] Active Directory and custom attributes & auxiliary objectclass
Pavol Mederly
mederly at evolveum.com
Mon Jul 6 16:05:12 CEST 2015
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
> Date : 02/07/2015 - 15:17 (BST)
> To : 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 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
>> 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/20150706/67f2092f/attachment.htm>
More information about the midPoint
mailing list