Fedora directory users - Nov 2008 - Many DSGW authentication problems

I''m finding several weird issues with DSGW authentication which make it
very difficult for our users to use.  Not to complain - great DS - but
we''re experiencing some problems.

We do not allow anonymous browsing of the tree.  Each client has a user
who has rights to search only their portion of the tree for possible
DSGW logins.  The ACI, place on the root, is thus:

(target
"ldap:///ou=Users,($dn),o=Internal,dc=ssiservices,dc=biz")(targetattr
"uid || st || sn || ou || name || entrydn || dn || dc || objectClass ||
cn || o || l || c || givenName") (version 3.0;acl "Client DSGW
Lister";allow (search,read)(userdn
"ldap:///uid=*dsgwlister,[$dn],o=sysaccounts,dc=ssiservices,dc=biz");)

We have an example test user named sue.sutter.  The full dn is
uid=sue.sutter,ou=users,o=a0000-0006,o=internal,dc=ssiservices,dc=biz

The first step is to go the authentication page where we read:
"The first step in authenticating to the directory is identifying
yourself."
This is why we created a user with rights to browse for other users and
defined it with a binddnfile entry.  That part is working fine.

If I enter sue.sutter, it does not find her directly but rather offers a
list with a single hyperlinked choice.  That''s the first problem (a
problem for anyone with a "." in their uid).  The query has replaced
the
"." with a space:
filter="(&(objectClass=person)(|(sn=sue sutter)(cn=sue sutter)))
I tried surrounding it with quotes and escaping it with a back slash but
the quote was interpreted literally and the back slash gave the same
results as the period alone.

Is this a bug, a configuration error, or just the way it''s supposed to
be? If the latter, this is very user unfriendly.  A techie might
understand escape characters or special encoding but not an everyday
user.

It wouldn''t be so bad if they could simply click on the hyperlink and
be
allowed to login.  However, the hyperlink does not work.  Mousing over
gives:
javascript:authSubmit(''uid%3Dsue.sutter%2Cou%3DUsers%2Co%3Da0000-0006%
2Co%3DInternal%2Cdc%3Dssiservices%2Cdc%3Dbiz'');%20onMouseOver
but it goes nowhere.  A packet trace shows no packets coming from the
browser to the DS.  What might we have configured incorrectly to cause
this? We see the same thing in Konqueror as we see in Firefox3 all
running on fully patched Ubuntu 8.0.4.

Hmmm . . . this is getting long.  I''ll put the other problem into
another email.  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

On Sat, 2008-11-29 at 19:14 -0500, John A. Sullivan III
wrote:
> I''m finding several weird issues with DSGW authentication which
make it
> very difficult for our users to use.  Not to complain - great DS - but
> we''re experiencing some problems.
> 
> We do not allow anonymous browsing of the tree.  Each client has a user
> who has rights to search only their portion of the tree for possible
> DSGW logins.  The ACI, place on the root, is thus:
> 
> (target >
"ldap:///ou=Users,($dn),o=Internal,dc=ssiservices,dc=biz")(targetattr
> "uid || st || sn || ou || name || entrydn || dn || dc || objectClass
||
> cn || o || l || c || givenName") (version 3.0;acl "Client DSGW
> Lister";allow (search,read)(userdn >
"ldap:///uid=*dsgwlister,[$dn],o=sysaccounts,dc=ssiservices,dc=biz");)
> 
> We have an example test user named sue.sutter.  The full dn is
> uid=sue.sutter,ou=users,o=a0000-0006,o=internal,dc=ssiservices,dc=biz
> 
> The first step is to go the authentication page where we read:
> "The first step in authenticating to the directory is identifying
> yourself."
> This is why we created a user with rights to browse for other users and
> defined it with a binddnfile entry.  That part is working fine.
> 
> If I enter sue.sutter, it does not find her directly but rather offers a
> list with a single hyperlinked choice.  That''s the first problem
(a
> problem for anyone with a "." in their uid).  The query has
replaced the
> "." with a space:
> filter="(&(objectClass=person)(|(sn=sue sutter)(cn=sue sutter)))
> I tried surrounding it with quotes and escaping it with a back slash but
> the quote was interpreted literally and the back slash gave the same
> results as the period alone.
> 
> Is this a bug, a configuration error, or just the way it''s
supposed to
> be? If the latter, this is very user unfriendly.  A techie might
> understand escape characters or special encoding but not an everyday
> user.
> 
> It wouldn''t be so bad if they could simply click on the hyperlink
and be
> allowed to login.  However, the hyperlink does not work.  Mousing over
> gives:
>
javascript:authSubmit(''uid%3Dsue.sutter%2Cou%3DUsers%2Co%3Da0000-0006%
> 2Co%3DInternal%2Cdc%3Dssiservices%2Cdc%3Dbiz'');%20onMouseOver> 
> but it goes nowhere.  A packet trace shows no packets coming from the
> browser to the DS.  What might we have configured incorrectly to cause
> this? We see the same thing in Konqueror as we see in Firefox3 all
> running on fully patched Ubuntu 8.0.4.
> 
> Hmmm . . . this is getting long.  I''ll put the other problem into
> another email.  Thanks - John
I should mention I also tried this after giving full rights to all
attributes to all portions of the tree to the browsing user but had the
exactly same results.  Thanks - John
-- 
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

John A. Sullivan III wrote:
> I''m finding several weird issues with DSGW authentication which
make it
> very difficult for our users to use.  Not to complain - great DS - but
> we''re experiencing some problems.
>
> We do not allow anonymous browsing of the tree.  Each client has a user
> who has rights to search only their portion of the tree for possible
> DSGW logins.  The ACI, place on the root, is thus:
>
> (target >
"ldap:///ou=Users,($dn),o=Internal,dc=ssiservices,dc=biz")(targetattr
> "uid || st || sn || ou || name || entrydn || dn || dc || objectClass
||
> cn || o || l || c || givenName") (version 3.0;acl "Client DSGW
> Lister";allow (search,read)(userdn >
"ldap:///uid=*dsgwlister,[$dn],o=sysaccounts,dc=ssiservices,dc=biz");)
>
> We have an example test user named sue.sutter.  The full dn is
> uid=sue.sutter,ou=users,o=a0000-0006,o=internal,dc=ssiservices,dc=biz
>
> The first step is to go the authentication page where we read:
> "The first step in authenticating to the directory is identifying
> yourself."
> This is why we created a user with rights to browse for other users and
> defined it with a binddnfile entry.  That part is working fine.
>
> If I enter sue.sutter, it does not find her directly but rather offers a
> list with a single hyperlinked choice.  That''s the first problem
(a
> problem for anyone with a "." in their uid).  The query has
replaced the
> "." with a space:
> filter="(&(objectClass=person)(|(sn=sue sutter)(cn=sue sutter)))
> I tried surrounding it with quotes and escaping it with a back slash but
> the quote was interpreted literally and the back slash gave the same
> results as the period alone.
>
> Is this a bug, a configuration error, or just the way it''s
supposed to
> be? If the latter, this is very user unfriendly.  A techie might
> understand escape characters or special encoding but not an everyday
> user.
>   
Sounds like a bug.  I have no idea why a "." would be replaced with a
space.
> It wouldn''t be so bad if they could simply click on the hyperlink
and be
> allowed to login.  However, the hyperlink does not work.  Mousing over
> gives:
>
javascript:authSubmit(''uid%3Dsue.sutter%2Cou%3DUsers%2Co%3Da0000-0006%
> 2Co%3DInternal%2Cdc%3Dssiservices%2Cdc%3Dbiz'');%20onMouseOver>
> but it goes nowhere.  A packet trace shows no packets coming from the
> browser to the DS.  What might we have configured incorrectly to cause
> this? We see the same thing in Konqueror as we see in Firefox3 all
> running on fully patched Ubuntu 8.0.4.
>   
Sounds like another bug.  Didn''t you already file a bug about this
issue?
> Hmmm . . . this is getting long.  I''ll put the other problem into
> another email.  Thanks - John
>