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>
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>
wrote:
Hi,
I second this ... and did the same.
Regards,
Anton
----Original
message----
From : jeverling at bshp.edu
Date : 06/07/2015 - 17:26 (BST)
To : 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>
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>
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
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
CustomsomeNameObjectClass,
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
_______________________________________________
midPoint mailing list
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
--
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/9762ae1a/attachment.htm>