untrusted domain authentication with AD oip

May 24, 2012 at 3:59 AM

Using an environment that connects to a domain/forest that is not trusted.  The MS AD oip connector works fine, but needing additional properties, I'm trying out some of these activities.  Whenever this connector tries to contact the untrusted domain with valid username/pw and domain (both fqdn and nebios name) it results in the access denied error below:

Logon failure: unknown user name or bad password.

Exception: DirectoryServicesCOMException
Target site: DirectoryEntry.Bind

Stack trace:
   at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.RefreshCache()
   at System.DirectoryServices.DirectoryEntry.FillCache(String propertyName)
   at System.DirectoryServices.PropertyCollection.KeysCollection.GetEnumerator()
   at Active_Directory.getObjectPropertyValues.<getValues>d__0.MoveNext()
   at Microsoft.SystemCenter.Orchestrator.Integration.Framework.Core.FilterSet.Filter(IEnumerable values)
   at Microsoft.SystemCenter.Orchestrator.Integration.Framework.Core.FilteredResponse.PublishRange(IEnumerable values)
   at Active_Directory.getObjectPropertyValues.Execute(IActivityRequest request, IActivityResponse response)

Not that it should matter: I'm using the 'Get object property values' action.  I've confirmed the object ldap path is correct and have a single action filter of Property_Name equals division.

I'm stuck!  I don't want to have to use posh or something less-native to get more properties than the default.

Would love to have the ability to define an ldap filter prior to the query so I don't have to filter on the back-end... a PC query with >15000 objects in the subtree gobbles up ram.

May 24, 2012 at 4:16 AM

I replaced the MS 'get computer' activity with the one from this AD ip and it is getting the dn so the auth is working.  the step to get the division property of a computer object is not, however.  This may be syntax within the object, but I'm not sure how to debug.

May 24, 2012 at 4:53 AM

one more update....  while the get dn works, get object propery fails with an untrusted domain.  if I switch to a trusted domain, everything is fine.  This seems to indicate that the oip, or at least this activity, is either not honoring the specified credentials in the connection or it may not be capable of operating in such an environment...  i did find it curious that the configuration properties were quite different between the MS ip and this one. 

Any suggestions would be greatly appreciated. 

oh, and did find that 3.1 has query filtering... very cool.. now I'd just like auth and the ability to specify attributes.

Thanks for sharing with the community!

May 24, 2012 at 2:02 PM

Thanks for the bug report, I will try to reproduce it.  Adressing your other feature requests (now I'd just like auth and the ability to specify attributes) I believe that you mean the following

Auth:  Successful athentication across untrusted domains / forests

The Ability to Specify Attributes:  The ability to limit which properties are returned by get object property value.  This is already implemented albiet not as efficiently as possible.  To utilize this functionality you add a 'filter' to the activity and set 'property name' 'equals' 'the property you want to return'.  For efficiency gains I will be updating the IP to support only fetching the properties you specify in the filters (if you set any filters).

If you are curious about how to debug integration packs the following post from Robert Hearn is very helpful.  You can do a custom compile of the integration pack (all source code for this project is available for public consumption) for testing with the invoke .net object http://blogs.technet.com/b/orchestrator/archive/2012/04/23/stepping-through-custom-activity-code-using-the-debugger.aspx

Let me know if this addresses your issues.

May 24, 2012 at 2:34 PM

I have successfully reproduce the error I will work on a fix, stay tuned

May 24, 2012 at 6:10 PM

The issue that was being encountered by the integration pack had to do with LDAP Pathing.  The path that was returned by get object distinguishedname was always of form LDAP://cn=this,ou=that,dc=contoso,dc=com.  The this always looks in your current forest for the object.  The correct format for the path should be of form LDAP://domain/cn=this,ou=that,dc=contoso,dc=com.  The 'get object distinguishedname' object has been updated to publish out the correct information for this scenario. 

May 24, 2012 at 8:24 PM

Great.  Look forward to the release.  Until then, I'll split/insert/join to rebuild the path with the current version.  yay!

May 24, 2012 at 8:25 PM

Working on getting it tested at the moment, had to update all of the published paths to be in the correct form ;-)

May 24, 2012 at 9:39 PM

please try http://scorch.codeplex.com/releases/view/88358 and let me know if this addresses your issues.



May 24, 2012 at 10:15 PM
Will test as soon as I get back to my lab.

Sent from my Windows Phone

From: randorfer
Sent: 5/24/2012 3:39 PM
To: cmcalvin@live.com
Subject: Re: untrusted domain authentication with AD oip [scorch:356918]

From: randorfer

please try http://scorch.codeplex.com/releases/view/88358 and let me know if this addresses your issues.



May 29, 2012 at 5:27 PM

any updates calvin?

Jun 4, 2012 at 3:36 PM

It is doing what I need!  Very nice....  Now I'm wishing there was an alternative to the kelverion bmc remedy ars oip.  I had to resort to creating helpdesk tickets using posh and their older com stuff.  Oh, and I'm not thrilled with the MS sharepoint oip either... again with cross-domain auth, I think list updates fail. :(

Jun 5, 2012 at 10:00 PM

Yeah we are in a similar situation with the BMC Remedy integration pack, not sure how we are going to address it yet.

Jun 5, 2012 at 10:19 PM

Going to continue this in a new discussion as I will get into a procedural discussion