Anonymous_User Absent Member.
Absent Member.
197 views

Populating an OID with LUM provided posix information


I am hoping you can provide some guidance on what I am trying to achieve
- or even tell me its not the best way!

We have IDM3.6.1, and we are trying to push the unix information to an
OID. Users are LUM enabled in eDir (same tree as IDM) so this is where
the gidNumber, uidNumber, uniqueID etc are generated.

The trace information isn't useful as it tells me an LDAP error
occurred. I've checked the usual suspects such as empty values being
passed through, but everything seems to have a value in the input doc. I
can provide a trace if needed, but its too large to post here.
I have also tried adding the posixGroup aux class to a group in the OID,
and populated what I can see is the mandatory fields, but it doesnt seem
to work either.

Thanks in advance,


--
phillipsw
------------------------------------------------------------------------
phillipsw's Profile: https://forums.netiq.com/member.php?userid=1113
View this thread: https://forums.netiq.com/showthread.php?t=46866

Labels (1)
0 Likes
6 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information

Post a trace. "An error occurred" without details is beyond unhelpful.
Without even the LDAP error, well, what can we do? I'll make some guesses
that won't help you:

Your OID box is turned off.
Your connection information to OID is wrong.
The context where you are placing your user is wrong.
The schema mapping between eDir and OID is wrong.
The credentials you specified... you guessed it... wrong.

The trace may not be as helpful as you'd like, but I'd bet it helps us get
close based on experience with other LDAP sources. The LDAP code means
something, and seeing the data going into the driver coupled with that
error code means more. Without that, well, see above. Use your favorite
pasting site if needed.... paste.opensuse.org is a local one, or there are
things like pastie or pastebin.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information


yeah ab, I am aware that without a trace is pretty difficult to
troubleshoot.

As requested; http://paste.opensuse.org/31595648
This is for the group only modification only. User one will follow.


--
phillipsw
------------------------------------------------------------------------
phillipsw's Profile: https://forums.netiq.com/member.php?userid=1113
View this thread: https://forums.netiq.com/showthread.php?t=46866

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information

Okay, this helps:

http://tools.ietf.org/html/rfc4511

From the RFC on LDAP we learn that a replace with no value doesn't do any
harm. This was something I wanted confirmed before responding because
only two things are actually working with values that were not there
before: description (replaced with no value, so either deleted or ignored
depending on if the object had a description, but it apparently did not
per the trace), gidNumber (replaced with a valid integer), and CN
(replaced with another value). Since the membership is a change (and
presumably a valid one) that leaves gidNumber and CN, both which I would
test in your environment.

The class involved is orclGroup, and since I do not know much/anything
about OID my guess is that this is similar to the 'group' class defined in
LDAP. Because I don't like assuming I checked with Google which took me here:

http://docs.oracle.com/cd/B14099_19/idmanage.1012/b15883/schema_objclass002.htm#BEIDAGEH

This, though, says something about "additional attributes" for the group
class. If this is similar to an eDirectory auxiliary class then the
schema mapping is probably the problem. Per the link above orclGroup
doesn't have much of anything available so what you probably need to do is
fix the schema mapping to point to (guessing) groupOfNames and then see if
synchronization works better. If not, my guess is that you'll need to add
a rule to make things like gidNumber available to the group if it not
already there. Synchronization to eDirectory via IDM does this
automatically, but I do not know that OID works the same way and would bet
it does not since most LDAP applications do not. Anytime, then, a
gidNumber attribute is added force (at the same time) an addition of the
object class which makes that attribute allowed on the group in OID. If
it is already there it should be optimized out.

Other things that could go wrong: changing the CN, when it is part of the
DN, is usually considered a rename event, especially since this has a
remove-all-values in it. I do not think this is the problem right now,
but it's something to be aware of. On the other hand, it looks like OID
has a value of BaSE-Administrators for the CN attribute in addition to the
part that is in the RDN, so perhaps it could work after all.

As a real test, though, feel free to create an LDIF and pump it into OID
via ldapmodify (or whatever other tool, like Apache Directory Studio) in
order to duplicate the symptom without IDM and to see how the proper
document should look. I would guess your current document would look like
like in an LDIF:


dn: cn=B-Administrators,cn=idm,cn=groups,dc=au
changetype: modify
replace: CN
CN: B-Administrators
-
replace: groupMember
groupMember: cn=user2,cn=idm,dc=au
groupMember: cn=user3,cn=idm,dc=au
groupMember: cn=user1,cn=idm,dc=au
-
replace: gidNumber
gidNumber: 606
-
replace: description


A last oddity.... the new membership DNs are not the same as the old ones
in their base. New ones end at cn=idm,dc=au, while old ones end with
cn=idm,cn=bcc,cn=users,dc=bcc,dc=qld,dc=gov,dc=au so that may or may not
be an issue.

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information


ab, thanks for the information. The last oddity is my mistake. I guess
the sanitation of the trace file was not as complete as I had hoped for
as I have left some dc's in the DN...


--
phillipsw
------------------------------------------------------------------------
phillipsw's Profile: https://forums.netiq.com/member.php?userid=1113
View this thread: https://forums.netiq.com/showthread.php?t=46866

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information

> ab, thanks for the information. The last oddity is my mistake. I guess
> the sanitation of the trace file was not as complete as I had hoped for
> as I have left some dc's in the DN...


No worries; you probably did a great search/replace, but they were in the
base64-encoded sections and, being a bit over-zealous, I decoded them.
Anyway, sorry if that was a bit overkill.

Did any of the rest help?

Good luck.
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Populating an OID with LUM provided posix information


Ah, that is thorough so thank you!

Yes, it did help to read more in depth on LDAP, and we now have it
working. I was trying to add "Object Class" at the sub output transform
instead of "objectclass", and OID didn't like that. Once I changed it, I
was able to add posixAccount and posixGroup (users and groups
respectively) classes and it's all working well for our purposes.

Thanks again,


--
phillipsw
------------------------------------------------------------------------
phillipsw's Profile: https://forums.netiq.com/member.php?userid=1113
View this thread: https://forums.netiq.com/showthread.php?t=46866

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.