1. UNIFYNow Forum
  2. Questions
0
Answered

eDirectory Agent unable to be created with Basic authentication

Bob Bradley 11 years ago • updated by anonymous 9 years ago • 9

I just shared a remote desktop session with Henry and his customer and he showed me what he described as a problem whereby the eDir and AD agent dialogs were seemingly being confused. This is hard to explain - basically when he had set up an eDir agent and tried to view the details, the labels were what you would expect for an AD agent, and vice versa.

Firstly I am logging this call on Henry's behalf because he doesn't yet have an Atlassian ID (he told me that Shane Day had organised something and that he should have had an email from the website by now, but there has been no email, and there is certainly no evidence of a Henry.Schleichardt user id). Henry has promised to email me with the details, but until he does, this issue serves as a placeholder for that further info.

What I then did was tell Henry to save a backup of his Extensibility folder, and then to delete all agents/connectors/groups - which he did. I then got him to recreate the FIM agent, then the AD agent, and check that it worked and fired the correct AD MA in FIM - which it did (although we couldn't get this working with Authentication type = Secure, and had to use Basic ... but that is another issue entirely - right now working with Basic was adequate).

So then with this working I got him to examine the created configuration and check that all the details were as expected - inspecting the LISTENER and the CHANGES settings for the first AD MA.

I then got him to repeat the exercise for eDir - and here is the first evidence of the problem ... when we chose "LDAP Agent" from the list of agents and clicked CREATE AGENT, Henry entered the name of the agent and the server DNS name ... then when he selected "Basic" from the drop-down list we were presented with the following fields to complete:

  • Domain
  • User
  • Password
  • Repeat Password

The problem of course is that the first property "Domain" is redundant here, since the user name being entered is in its full DN format (Henry's screenshots will show you this - details as he is using in the eDir MA's connection details itself). Since this field is shown as MANDATORY, we had to enter SOMETHING - I suggested that this looks like a bug but for the time being we could re-enter the server DNS name. This was accepted but of course when we enabled the operation it failed.

So at this point we are stuck with not being able to configure the agent correctly for eDir. We also tried anonymous, but this didn't work in this case either (we weren't sure if some level of anonymous was allowed, but it appears not - it was a long shot regardless!).

For the time being I have advised Henry to simply delete the check operation and to run the eDir DI/DS run profile at intervals of say 10 minutes.

Could you please have a look at this Agent with an eDir instance (I believe Eddie Kirkman has a working instance of one if you need one) and see if you can see the same problem? Ideally then get back to Henry asap with either advice on what he/we have done incorrectly or a patch to fix what could be a bug.


EB-config.jpg
s1.jpg
s2.jpg
UnifyLog20130719.csv
Bob Bradley 11 years ago

From: Henry Schleichardt Henry.Schleichardt@infowan.de
Sent: Wednesday, 3 July 2013 11:33 PM
To: Shane Day
Cc: Bob Bradley
Subject: EventBroker Trouble

Hello Shane
While installing EventBroker at Fraunhofer I tried to configure one LDAP agent and one Active Directory agent
Please have a look at the screenshots
The name and the configuration options are mixed up in the current EventBroker Version.
We had trouble to configure the eDir Agent with the required credentials in the right LDAP-specific format.
Right now, we can only connect anonymously but this is not sufficient.

Bob was so kind to help us and had a short look at our setup. He confirmed the problem.

For your further testing with the current EventBroker version, we are connecting to an eDir with the version: 8.8 SP7 Version 20704.00

We now wait for an update.
Cheers, Henry

AD

And LDAP

Mit freundlichen Grüßen
With kind regards

Henry Schleichardt

Adam van Vliet 11 years ago

Hi Henry,

The domain field was mistakenly set as required.

I will schedule the fix for the next version.

In the meantime, I can either fix up your configuration for you, or simply follow these instructions:
1. Create a new LDAP Agent using the desired settings, with the domain SomeDomain (just to get through validation).
2. Stop FIM Event Broker.
3. Open Unify.Product.EventBroker.AgentEnginePlugInKey.extensibility.config.xml (a default installation will be C:\Program Files\UNIFY Solutions\Event Broker\Services\Extensibility\Unify.Product.EventBroker.AgentEnginePlugInKey.extensibility.config.xml).
4. Search for the agent of name="your agent name" type="Unify.EventBroker.Agent.OpenLDAP".
5. Delete the domain attribute and value.
6. Save the file.
7. Start FIM Event Broker.

Please let me know if you have any issues.

Adam van Vliet 11 years ago

Hi Henry,
Was your customer able to successfully connector to their LDAP system?

Adam van Vliet 11 years ago 
20130719,07:32:17,FIM Event Broker,Operations,Error,"Operation 3ae0f465-f9b5-43d1-9463-96b334710d91 failed in operation list with id afd1238e-19eb-462c-a631-0d6eb8dfca84 for the following reason. This is retry number 0: System.DirectoryServices.Protocols.DirectoryOperationException: The server cannot handle directory requests.
   at System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)
   at System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
   at Unify.Product.EventBroker.OpenLDAPChangesPlugIn.Check()
   at Unify.Product.EventBroker.OperationListExecutorBase.RunCheck(ICheckOperationFactoryInformation checkOperation)",Normal
Patrick Johannessen 11 years ago

Email to Henry and Christian:

Good evening,

I've been working with Adam the last few days to try and determine the cause of the issue you're experiencing.

As he mentioned earlier in the week, our Novell expert is on leave so I've done what I can to brush up on my LDAP knowledge and I believe I've made a change for you that may fix your issue. I've tested it against an eDirectory instance we've set up here so I'm hopeful that it will resolve your issue.

Before we think about a full release we'd like you to test the change for yourself, so if possible we'd like you to patch it by placing a new DLL in to the Services directory of your FIM Event Broker service. I've attached the DLL to our knowledge management system for download. I believe only Henry has access to it, so I'll also send it along in an email after this one, but I'm a little less sure that will make it to you as Exchange often rejects DLLs: https://unifysolutions.jira.com/wiki/display/INFOWAN/Downloads

I've included an explanation for why I believe this issue is occurring in case you're interested, as it may explain why we haven't encountered it before. I'll be working with one of our LDAP experts to try and clarify it for me and identify a more permanent solution in future;

Our LDAP changes plugin utilizes Server Side Sorting to retrieve the latest "modifyTimestamp" value from the specified LDAP container. This prevents us from having to loop through every single entry in the container, which could take a long time (particularly on the first run), as it allows us to order by the timestamp and only request the first object.

This link suggests that only a subset of Server Side Sorting is supported in eDirectory: http://www.novell.com/support/kb/doc.php?id=7001493

I don't think we're explicitly violating any of the limitations listed there, but removing the control worked; so we either are violating it, or the LDAP API we're using relies on the sorting OID being listed in the Root DSE. To get around performance issues the first time the check operation is run, I set a timestamp of the current UTC date instead of retrieving it from eDirectory; this produce exactly the same result, but I don't know whether it will work for other, non-eDirectory stores as the modifyTimestamp format seems to be different between LDAP implementations.

In the next version I'll look to include additional options on the configuration screen so you can select whether to use things like server side sorting, paging, etc.

Thank you for your patience with us so far, looking forward to hearing from you about whether this resolves your issue.

Kind regards,

Patrick Johannessen

When Eddie Kirkman gets back from leave we might be able to learn more about this.

Adam van Vliet 11 years ago

Hi Patrick Johannessen, could you please update this with the latest information?

Patrick Johannessen 11 years ago

Fix pushed to INFOWAN-2 branch. Shouldn't be applied to the main branch - we instead need to upgrade it in the next version to support more configurable options so that it's more cross-platform.

Patrick Johannessen 11 years ago

See EB-652 for a permanent fix in future.

Patrick Johannessen 11 years ago

From Christian, 06/08/13:

Hello Patrick,

Thank you fort hat hint. Unblocking the 'dll' worked.

I stopped/started the service and then did enable the check operation. Now it works without errors (log file attached).

Customer support service by UserEcho