• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Active Directory, JNDI, EOModel
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Active Directory, JNDI, EOModel


  • Subject: Re: Active Directory, JNDI, EOModel
  • From: Tim Worman <email@hidden>
  • Date: Mon, 24 Jul 2017 11:43:20 -0700

Using Wireshark, below is what I’m seeing for the two queries. The biggest
difference right off the bat is that the WO/EOModel search seems to search ROOT
as the base DN whereas the Apache DirectoryStudio is using
“DC=adinstance,DC=ucla,DC=edu” as the base. The WO/EOModel search also appears
to have additional objectClass ‘AND’ filters.

Looks like my first guess was somewhat likely - I need to find a way to get a
handle on the query and feed a base DN to my fetch in WO.

It looks like this might be a way to set that:
JNDIPlugin - base
<http://wocommunity.org/documents/javadoc/WebObjects/5.4.2/com/webobjects/jndiadaptor/JNDIPlugIn.html#base(com.webobjects.eocontrol.EOFetchSpecification, com.webobjects.eoaccess.EOEntity)>

But I’m wondering if there is a way to set it once at the launch of an app and
not have to set it again.

--------------------------------------------

From WebObjects:
Lightweight Directory Access Protocol
    LDAPMessage searchRequest(2) "<ROOT>" wholeSubtree
        messageID: 2
        protocolOp: searchRequest (3)
            searchRequest
                baseObject:
                scope: wholeSubtree (2)
                derefAliases: derefAlways (3)
                sizeLimit: 0
                timeLimit: 3601
                typesOnly: False
                Filter: (objectClass=user)
                    filter: and (0)
                        and: (objectClass=user)
                            and: 1 item
                                Filter: (objectClass=user)
                attributes: 0 items
        [Response In: 8]
        controls: 1 item
            Control
                controlType: 2.16.840.1.113730.3.4.2 (Manage DSA IT LDAPv3
control)

From Apache Directory Studio:
Lightweight Directory Access Protocol
    LDAPMessage searchRequest(14) “DC=adinstance,DC=ucla,DC=edu" wholeSubtree
        messageID: 14
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: DC=adinstance,DC=ucla,DC=edu
                scope: wholeSubtree (2)
                derefAliases: derefAlways (3)
                sizeLimit: 1000
                timeLimit: 0
                typesOnly: False
                Filter: (objectClass=user)
                    filter: equalityMatch (3)
                        equalityMatch
                            attributeDesc: objectClass
                            assertionValue: user
                attributes: 2 items
                    AttributeDescription: cn
                    AttributeDescription: objectClass
        [Response In: 2]


> On Jul 21, 2017, at 12:58 PM, Chuck Hill <email@hidden> wrote:
>
> Try going through a proxy like Charles.  Comparing what is sent from WO and
> from Directory Studio might highlight what is wrong.  I am sure that I did
> this many years ago, but the details escape me.  Microsoft’s standard is just
> a little…different.
>
> Chuck
>
> On 2017-07-21, 12:56 PM, "Webobjects-dev on behalf of Tim Worman"
> <webobjects-dev-bounces+chill=email@hidden on behalf of
> email@hidden> wrote:
>
>    Yeah, I’m not using the model for authentication to AD, I’m intending to
> use simply to return EO's from AD. I’m encountering the error below when I
> simply try:
>
>    ADUser.fetchAllADUsers(pageEditingContext());
>
>    The WARN log seems to indicate that I can’t search objectClass “user.” But
> it is modeled and was reverse engineered. I’m unsure why that would be
> considering I haven’t had that issue before with other ldap services.
>
>    Tim
>
>> On Jul 21, 2017, at 12:50 PM, Theodore Petrosky <email@hidden> wrote:
>>
>> did you see this:
>>
>> https://www.slideshare.net/wocommunity/third-party-auth-in-webobjects
>>
>> I was looking to see if there was a video to go along with the slides but
>> didn’t find one.
>>
>>
>>> On Jul 21, 2017, at 3:10 PM, Tim Worman <email@hidden> wrote:
>>>
>>> Has anyone used the JNDI plugin to model Active Directory? I’ve used it
>>> with a lot of success with other ldap directories but I’m running into a
>>> problem with a pretty simple model (which I’m sure has to do with AD’s
>>> implementation).
>>>
>>> I reverse engineered our AD (Server 2016) instance with no problem - and
>>> only included Person and User in my model. However, when I try to do a
>>> simple fetch of all User (or Person) I get sth like:
>>>
>>> Jul 21 11:11:23 GSEISNetTestApplication[54777] DEBUG NSLog  - Waiting for
>>> requests...
>>> Jul 21 11:11:24 GSEISNetTestApplication[54777] WARN
>>> er.extensions.eof.ERXModelGroup  - Clearing previous class descriptions
>>> Jul 21 11:11:24 GSEISNetTestApplication[54777] DEBUG NSLog  - Context
>>> factory cache is already clear
>>> Jul 21 11:11:24 GSEISNetTestApplication[54777] DEBUG NSLog  - Connecting:
>>> {plugInClassName = "com.webobjects.jndiadaptor.LDAPPlugIn"; timeout =
>>> "3600"; scope = "Subtree"; username = "CN="Application Server",OU="Service
>>> Accounts",OU=ETU,DC=gseisnet,DC=ucla,DC=edu"; authenticationMethod =
>>> "Simple"; password = "<omitted from log>"; serverUrl =
>>> "ldap://gseisnet.ucla.edu:389";; initialContextFactory =
>>> "com.sun.jndi.ldap.LdapCtxFactory"; }
>>> Jul 21 11:11:24 GSEISNetTestApplication[54777] DEBUG NSLog  - Creating
>>> plug-in com.webobjects.jndiadaptor.LDAPPlugIn for JNDIAdaptor@1084219182
>>> Jul 21 11:11:24 GSEISNetTestApplication[54777] WARN  NSLog  - Cannot search
>>> (&(objectClass=user))
>>> [2017-7-21 11:11:24 PDT] <WorkerThread0>
>>> javax.naming.NameNotFoundException: [LDAP: error code 32 - 0000208D:
>>> NameErr: DSID-0310021B, problem 2001 (NO_OBJECT), data 0, best match of:
>>>     ''
>>> ]; remaining name ''
>>>
>>> When I use Directory Studio to perform what appears to be the same search,
>>> filtering on objectClass user, I get the results I would expect. I’m using
>>> the same bind credentials in both as well. One guess I have is the search
>>> base, which I have set to the base DN in Directory Studio. Is there a way
>>> to get a handle on the JNDI adaptor and set the search base globally in
>>> case it isn’t right?
>>>
>>> Any other ideas? I know I’m probably off the reservation here.
>>>
>>> Tim
>>> UCLA GSE&IS
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Webobjects-dev mailing list      (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
>     _______________________________________________
>    Do not post admin requests to the list. They will be ignored.
>    Webobjects-dev mailing list      (email@hidden)
>    Help/Unsubscribe/Update your Subscription:
>
>
>    This email sent to email@hidden
>
>

 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • Re: Active Directory, JNDI, EOModel
      • From: Chuck Hill <email@hidden>
References: 
 >Active Directory, JNDI, EOModel (From: Tim Worman <email@hidden>)
 >Re: Active Directory, JNDI, EOModel (From: Theodore Petrosky <email@hidden>)
 >Re: Active Directory, JNDI, EOModel (From: Tim Worman <email@hidden>)
 >Re: Active Directory, JNDI, EOModel (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: ERCoreBusinessLogic
  • Next by Date: Re: Active Directory, JNDI, EOModel
  • Previous by thread: Re: Active Directory, JNDI, EOModel
  • Next by thread: Re: Active Directory, JNDI, EOModel
  • Index(es):
    • Date
    • Thread