In Identitiy manager bidirectional driver sync not working

[KSEB1]

In novell Identity manager bidirectional driver sync not working.can anyone please suggest

[KSEB1]

In log it is showing - LDAPInterface.doLDAPAdd() Error: LDAPException: Insufficient Access Rights (50) Insu
fficient Access Rights
LDAPException: Server Message: NDS error: no access (-672)

[aburgemeister]

If you did not specify a user with sufficient privileges either as the
local security equivalence or with the remote tree, then that would cause
a -672. Where the rights need to be given depends on where the rights are
lacking. Post a level three (3) trace of driver startup and we'll look at it.

If you are in a hurry, you may want to call Micro Focus for official support.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[KSEB1]

https://drive.google.com/open?id=1PlrYOqBm48jKO0JXCikdyJqiyXFeYtlh

Please find the attached link for IDVto edirectory trace log.

[KSEB1]

GCV values https://drive.google.com/open?id=1QWtHcIRuq0QCzTAO3WgIkiUrdWVz0vlG

[aburgemeister]

There are several inconsistencies here.

Your original complaint was about a -672 error, which I do not see
anywhere in the trace. Where is that?

Also, it appears you are using TCP 389, which generally you should not as
there is no guarantee of privacy, unless you happened to use TLS/SSL on
that port instead of 636, which you so far have not done.

Also, for some reason you have your driver config pointing to 127.0.0.1
which is your vault box. Using this as a Null or loopback type of driver
config is not recommended; you should be pointing this to another tree.
Maybe you are, and just have a really odd setup on this box, but I think
it more likely this is a misconfiguration.

It may help if you describe when this worked last, how it broke since
then, and what its purpose is. If you are starting with a new system, you
should do this in a test environment. If you have a consultant or
somebody setting this up for the first time (or if you are that
consultant), you should setup a test environment to understand the
technology before deploying it in Production.

IDM is a wonderful technology, and used properly it will save tons of
mistakes, money, and improve security in an environment. Used
incorrectly, it can do bad things as easily as it can do good things
(maybe more easily). Great power, great responsibility, etc.

A driver config startup trace would still be appreciated, though the GCV
screenshots show some of what was sought.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[KSEB1]

Your original complaint was about a -672 error, which I do not see
anywhere in the trace. Where is that?

Actually now iam testing in test environment to resolve the issue.Yesterday the trace i was sent is the test environment driver start trace.

Also, it appears you are using TCP 389, which generally you should not as
there is no guarantee of privacy, unless you happened to use TLS/SSL on
that port instead of 636, which you so far have not done.

Also, for some reason you have your driver config pointing to 127.0.0.1
which is your vault box. Using this as a Null or loopback type of driver
config is not recommended; you should be pointing this to another tree.
Maybe you are, and just have a really odd setup on this box, but I think
it more likely this is a misconfiguration.

It may help if you describe when this worked last, how it broke since
then, and what its purpose is. If you are starting with a new system, you
should do this in a test environment. If you have a consultant or
somebody setting this up for the first time (or if you are that
consultant), you should setup a test environment to understand the
technology before deploying it in Production.

I have checked in test environment it was working.I tested in test environment in this also sync is not working.

IDM is a wonderful technology, and used properly it will save tons of
mistakes, money, and improve security in an environment. Used
incorrectly, it can do bad things as easily as it can do good things
(maybe more easily). Great power, great responsibility, etc.

A driver config startup trace would still be appreciated, though the GCV
screenshots show some of what was sought.


Any trace needed to find the issue..Any suggestion ?

[KSEB1]

Please find the attached latest level 3 trace log for the driver
https://drive.google.com/open?id=1quUViLS0brtffjikrMnB9cgYiP1UIPqa
Please suggest

[geoffc]

On 5/27/2019 1:06 AM, KSEB wrote:
>
> Please find the attached latest level 3 trace log for the driver
> https://drive.google.com/open?id=1quUViLS0brtffjikrMnB9cgYiP1UIPqa

That is a good trace sample.

Again, did you do what Aaron or I suggested? Did you check the
effective rights of the user in the remote eDir that the driver logs in as?

Does it have sufficient permission to write an objct in the container:
dn: CN=0000002,OU=Assistant Engineer,OU=KSEB_Designation,O=kseb

Does it have permissions to write to all the attributes in the event?

05/26/19 16:20:41.782]:IDVtoEdir ST:IDV to Edir: LDAP Add:
dn: CN=0000002,OU=Assistant Engineer,OU=KSEB_Designation,O=kseb
pan: AKTPA5941K
passwordUniqueRequired: <content suppressed>
passwordExpirationTime: <content suppressed>
passwordExpirationInterval: <content suppressed>
designationTypeId: 2
statusStartOn: 2015-09-03
loginDisabled: false
loginGraceLimit: 10
passwordRequired: <content suppressed>
designationId: 182
serviceStatusId: 1
passwordMinimumLength: <content suppressed>
KsebAcessBar: SCM||AESN||4679
KsebAcessBar: HRIS||HRIS_ROLE||4679
KsebAcessBar: SARAS||SARAS_ROLE||4679
KsebAcessBar: ORUMANET||ORUMA_ROLE||4679
KsebAcessBar: CCC-ET||ROLE_ADMIN||4679
KsebAcessBar: CCC-ET||ROLE_ADMIN||4501
KsebAcessBar: CCC-ET||ROLE_ADMIN||4502
KsebAcessBar: CCC-ET||ROLE_ADMIN||5731
KsebAcessBar: CCC-ET||ROLE_ADMIN||5732
KsebAcessBar: CCC-ET||ROLE_ADMIN||5541
designation: Assistant Engineer
serviceStatus: Duty
statusCode: DUTY
statusUpdateOn: 2016-06-01
ACL: 2#entry#[Self]#[All Attributes Rights]
ACL: 6#entry#[Self]#loginScript
ACL: 2#entry#[Public]#messageServer
ACL: 2#entry#[Root]#groupMembership
ACL: 6#entry#[Self]#printJobConfiguration
ACL: 2#entry#[Root]#networkAddress
ACL: 47#entry#[Self]#passwordAllowChange
position: Computer Programmer(NQ)
code: 4679
objectclass: inetOrgPerson
objectclass: organizationalPerson
objectclass: Person
objectclass: ndsLoginProperties
objectclass: Top
birthDate: 1978-04-25
employeeType: Regular
officeName: Poonthura Electrical Section
loginGraceRemaining: 10
passwordAllowChange: <content suppressed>
sn: t f
lastModifiedTimestamp: 2016-05-28 13:19:52
employeeName: TEST T F
employeeCode: 0000002
designationType: Officers
employeeTypeId: 1
userpassword: <content suppressed>
fullName: TEST T F
givenname: test hi
cn: 0000002
retirementDate: 2034-04-30
joinDate: 2006-09-11
employeeStatus: Active
positionId: 32
title: Assistant Engineer

[05/26/19 16:20:41.785]:IDVtoEdir ST:IDV to Edir: OpenLDAPConnection -
Connect to the server
[05/26/19 16:20:41.785]:IDVtoEdir ST:IDV to Edir: Opening clear text
connection
[05/26/19 16:20:41.791]:IDVtoEdir ST:IDV to Edir: WARNING !!!
WARNING !!! WARNING !!!
[05/26/19 16:20:41.791]:IDVtoEdir ST:IDV to Edir: You are using a
clear-text connection.
[05/26/19 16:20:41.791]:IDVtoEdir ST:IDV to Edir: The user password will
be sent in plain-text, which can be sniffed easily.
[05/26/19 16:20:41.791]:IDVtoEdir ST:IDV to Edir: It is recommended to
use SSL to secure the connection.

[05/26/19 16:20:41.793]:IDVtoEdir ST:IDV to Edir: Host name: 10.0.1.32
[05/26/19 16:20:41.793]:IDVtoEdir ST:IDV to Edir: Port: 389
[05/26/19 16:20:41.794]:IDVtoEdir ST:IDV to Edir: DN: null
[05/26/19 16:20:41.794]:IDVtoEdir ST:IDV to Edir: Protocol version=3
[05/26/19 16:20:41.794]:IDVtoEdir ST:IDV to Edir: SDK version=4.5
[05/26/19 16:20:41.799]:IDVtoEdir ST:IDV to Edir:
LDAPInterface.doLDAPAdd() Error: LDAPException: Insufficient Access
Rights (50) Insufficient Access Rights
LDAPException: Server Message: NDS error: no access (-672)

[KSEB1]

what i have done is i deleted the user from edirectory.Then i deleted the association of this user.The i tried manually migrate from identity vault.When trying this the error showing above..
How to check remote edir rights?

[aburgemeister]

That is not what was asked; have you verified rights of the user being
used to connect to the remote eDirectory tree itself, perhaps by creating
this user manually via something like Apache Directory Studio using the
user you have configured within your driver config object for the remote
tree: cn=admin,o=kseb

That user sounds like a tree administrator, so assuming you do not have
any odd rights setup or restricted within that remote tree my next guess
is that you have forgotten to set the password within the driver
configuration object. Where you see cn=admin,o=kseb there should be a
password field nearby. Set the password for that user in there. It
should not show up in the driver config trace, but it will let the
authentication happen properly.

Why would you get an LDAP error other than an LDAP 49 without a password
set? If you forget to set the password then, per LDAP standard's RFCs,
your connection automatically defaults to be anonymous, which may mean you
can continue interacting with the server, but it means you lack the rights
needed to create/modify.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.

[KSEB1]

If we set new password it will affect other user,or we want to set the application password as same password of idm application password or edir application password?
Please suggest?