Shibboleth Developers

[Dan McLaughlin <>]

Hi Daniel,

MSAD is fine as well. Another typo...  userField instead of
userFilter.  It took a little bit of starring at the screen before my
eyes picked up on it. ;)

I also found the reason the eDir configuration failures.  A Sun JDK
bug that was filed actually pointed me in the right direction.

http://bugs.sun.com/bugdatabase/view_bug.do;jsessionid=cd785fee3c55f87daca6ed15d2e0?bug_id=6201517

As the code entered the readCompositeName method, the string passed in
as s was "ldap://ldap01:636/cn=JDOE-C,ou=FOO,ou=BAR,o=DIV";.  The
problem was the cName.get(0) only retrieves a component of the
composite name, in this case the index is 0 or ldap:, so when it was
returned to URI.create it would fail.   I think what you were
intending was to use the toSting() method in this case.  I changed the
code to use cName.toString() in place of cName.get(0) and now
everything is working fine.

Here is the patch...

Index: 
src/main/java/edu/vt/middleware/ldap/handler/FqdnSearchResultHandler.java
===================================================================
--- src/main/java/edu/vt/middleware/ldap/handler/FqdnSearchResultHandler.java 
  (revision
1993)
+++ src/main/java/edu/vt/middleware/ldap/handler/FqdnSearchResultHandler.java 
  (working
copy)
@@ -100,7 +100,7 @@
     String name = "";
     try {
       final CompositeName cName = new CompositeName(s);
-      name = cName.get(0);
+      name = cName.toString();
     } catch (InvalidNameException e) {
       if (this.logger.isErrorEnabled()) {
         this.logger.error("Error formatting name: " + s, e);


--

Thanks,

Dan McLaughlin


NOTICE: This e-mail message and all attachments transmitted with it
are for the sole use of the intended recipient(s) and may contain
confidential and privileged information. Any unauthorized review, use,
disclosure or distribution is strictly prohibited. The contents of
this e-mail are confidential and may be subject to work product
privileges. If you are not the intended recipient, please contact the
sender by reply e-mail and destroy all copies of the original message.



On Thu, Jun 9, 2011 at 9:37 AM, Dan McLaughlin
<>
 wrote:
> Correct.
>
> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a never "(cn=jdoe-c)"
> returned the alias entry and the user entry
>
> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a never
> "(&(cn=jdoe-c)(objectclass=person))" returned only the user entry
>
> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a always "(cn=jdoe-c)"
> returned two identical user entries
>
> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a always
> "(&(cn=jdoe-c)(objectclass=person))" returned two identical user
> entries
>
>
> --
>
> Thanks,
>
> Dan McLaughlin
>
>
> NOTICE: This e-mail message and all attachments transmitted with it
> are for the sole use of the intended recipient(s) and may contain
> confidential and privileged information. Any unauthorized review, use,
> disclosure or distribution is strictly prohibited. The contents of
> this e-mail are confidential and may be subject to work product
> privileges. If you are not the intended recipient, please contact the
> sender by reply e-mail and destroy all copies of the original message.
>
>
>
> On Thu, Jun 9, 2011 at 8:03 AM, Daniel Fisher 
> <>
>  wrote:
>>
>> On Wed, Jun 8, 2011 at 6:24 PM, Dan McLaughlin
>> <>
>>  wrote:
>> > I agree the old properties are valid, but there is some bug that is
>> > causing aliases to be dereference regardless.  I think you would agree
>> > the following two configuration examples should NEVER dereference
>> > aliases.  If  dereference aliases is set to never and I search the
>> > entire tree and I have one alias that points to one user, then only
>> > the one user should be returned.  Correct?
>>
>> I would expect the user entry and the alias entry to be returned. To
>> confirm this try the following:
>> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a never "(cn=jdoe-c)"
>>
>> If an alias is not dereferenced, the alias entry is returned.
>>
>> then try:
>> ldapsearch -H ldaps://ldap01:636 -x -b o=org -a never
>> "(&(cn=jdoe-c)(objectclass=person))"
>> and confirm only the user entry is returned.
>>
>> --Daniel Fisher
>