added myself to the CC list

What version of Hudson did you have this problem in? There was a bug between
1.255 and 1.260 that caused the authorization strategy to revert after Hudson is
restarted. 1.261 has a partial fix which will prevent this reversion, but
exposed another problem where the security setting on individual projects was
not remembered. This is fixed in 1.262.

Adding myself to cc

For those who are seeing this problem, please report more details about your set
up. What security realm do you use, what container do you run Hudson in, where
did you set your permissions (is that in a project or in the system config?) Did
you get any stack trace with the error message? etc.

closing this one.. please reopen if anyone still sees this and provide more
detail as kohsuke requested. There have been several fixes in project-specific
permissions in the last couple months, so hopefully this one is resolved. Also
see issue 2324 regarding read permission at project level.

• • • Issue 2375 has been marked as a duplicate of this issue. ***

The message when opening Hudson's URL in a browser for the first time since the
browser is started:

Access Denied

org.acegisecurity.providers.rememberme.RememberMeAuthenticationToken@70307871:
Username: org.acegisecurity.userdetails.ldap.LdapUserDetailsImpl@7030cb29;
Password: [PROTECTED]; Authenticated: true; Details:
org.acegisecurity.ui.WebAuthenticationDetails@ffff4c9c: RemoteIpAddress:
MY_IP_ADDRESS; SessionId: null; Granted Authorities: is missing Read

When logging out and re-logging in it works as long as the window with Hudson's
UI is open and autorefresh is enabled or Hudson's plugin installed in FF.

LDAP binding is defined in Hudson's config:

Security Realm: LDAP
root DN: dc=myorg,dc=org
User search base: ou=Users
User search filter: cn=

, and not
uniqueMember=

) (uniqueMember=

))"
}
"

This patch works up to ver. 1.279. It also seemed to work with 1.280, but
finally we were locked with auth errors and unable to log in at all, which was
even more weird than the original issue.

The servlet container running Hudson is Apache Tomcat 6.0.16 with (more or less)
default configuration.

questions:
1) what permissions are granted to Anonymous, and are other permissions granted
directly to particular users or are you using groups?
2) does the problem only occur when you clicked "remember me" when logging in?
if you remove all hudson cookies and then visit the site, any errors?

adding myself as CC

> 1) what permissions are granted to Anonymous,
Anonymous - no permissions at all

> and are other permissions granted directly to particular users or are you
using groups?
mostly groups, but there are certain users too, although the user on which I am
testing this issue is not listed there directly, it just belongs to some of the
groups

> 2) does the problem only occur when you clicked "remember me" when logging in?
yes

> if you remove all hudson cookies and then visit the site, any errors?
no errors, just asks for login and password - seems that when this cookie is
present - ACEGI_SECURITY_HASHED_REMEMBER_ME_COOKIE - the the problem can be seen

confirmed.. I did some tests and found that the group lookup is not done when
you get logged in via the remember-me cookie. So you're logged in, but Hudson
doesn't know what groups you are in. In your case where there is no public read
access, you are then locked out. researching fix/workaround..

We've been just checking with the newest available (1.282) version and the issue
still happening.
Of course I needed to apply our LDAP-compatibility patch into
"LDAPBindSecurityRealm.groovy" file.
For current (1.282) Hudson version the patch looks a little bit different than
given in the previous comments (for 1.279), due to change in
"authoritiesPopulator" method signature:

• • • LDAPBindSecurityRealm.groovy 2009-02-08 22:09:52.000000000 +0000
    • ../patched/LDAPBindSecurityRealm.groovy 2009-02-13 07:39:49.000000000 +0000
      ***************
    • 62,67 ****
    • 62,68 ----
      authoritiesPopulator(DefaultLdapAuthoritiesPopulator,
      initialDirContextFactory, Util.fixNull(instance.groupSearchBase))
      Unknown macro: { // see DefaultLdapAuthoritiesPopulator for other possible configurations searchSubtree = true;+ groupSearchFilter = "(|(member={0}) (uniqueMember={0}))"; }

authenticationManager(ProviderManager) {

Created an attachment (id=558)
LDAPBindSecurityRealm.groovy - patched to work with our LDAP

I've attached also the patched version of LDAPBindSecurityRealm.groovy

I found that the remember-me service uses the UserDetailsService created in
Hudson's LDAPSecurityRealm.createSecurityComponents() to do the user lookup, and
the LdapUserSearch used in there does not do a group lookup. I can add this,
doing just what acegi's LdapAuthenticationProvider.createUserDetails() does to
lookup and add granted authorities before returning the final UserDetails.

r15290 | mindless | 2009-02-13 09:49:36 -0700 (Fri, 13 Feb 2009) | 2 lines
Changed paths:
M /trunk/hudson/main/core/src/main/java/hudson/security/LDAPSecurityRealm.java
M /trunk/www/changelog.html

[FIXED JENKINS-2329] LDAP group permissions were not applied when logged in via
remember-me cookie.

For me the issue with remember-me cookie now works (tested on Hudson ver. 1.288).
Although I still need to apply the patch to LDAPBindSecurityRealm.groovy to
tweak it to my LDAP structure, but that seems to be a different issue.
Thanks for resolving it!

Kind regards,
Krystian Nowak

great, thanks.. FYI, soon you shouldn't need the groovy patch.. it seems in some
restructuring in 1.280 that setting was lost, but we'll get it added back. see
issue #2256

Thanks for info on #2256! So, I'll just wait for Hudson 1.289 and we'll see

Regards,
Krystian Nowak