archiva-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Jacobs <Chris.Jac...@apollogrp.edu>
Subject RE: LDAP authentication
Date Mon, 14 May 2012 16:43:08 GMT
Brett,

The (bare) config I ended with security.properties (same issue whether in archiva/conf or
archiva/apps/archiva/WEB-INF/classes/org/apache/maven/archiva/security.properties - just tested
this AM):

user.manager.impl=ldap
security.policy.password.expiration.enabled=false
ldap.bind.authenticator.enabled=true
ldap.config.hostname=ldap-vip.example.net
ldap.config.port=389
ldap.config.base.dn=ou=people,dc=unix,dc=aptimus,dc=net
ldap.config.context.factory=com.sun.jndi.ldap.LdapCtxFactory
ldap.config.mapper.attribute.email=mail
ldap.config.mapper.attribute.fullname=cn
ldap.config.mapper.attribute.password=userPassword
ldap.config.mapper.attribute.user.id=uid
ldap.config.mapper.attribute.user.base=ou=people;dc=example;dc=net
ldap.config.mapper.attribute.user.object.class=inetOrgPerson
redback.default.admin=archiva-admin
redback.default.guest=archiva-guest

With a clean setup (puppet isn't doing anything other than placing conf files, which I'm not
doing as I don't have the configs nailed down yet).

The archiva-admin and archiva-guest LDAP accounts exist, but I'm unable to login as archiva-admin
using the LDAP credentials.

The non-puppetizable (in a sane manner) is:
* starting Archiva with its default config (only specifying the redback.default.admin property)
* setting up archiva-admin a password (which Archiva then wants to immediately reset? neato)
* shutting down Archiva
* putting in the configs as above or below
* starting Archiva up again.

When I login as archiva-admin after that it always takes me to the password change screen,
but I can ignore it and used the menu on the left, and I can login using my own LDAP credentials.

>From what I've read online, this seems to be the 'process' that's been successful in getting
Archiva using LDAP for user authentication.

I'm really hoping I've missed something and the steps above aren't in fact necessary.

Thanks,
- chris

-----Original Message-----
From: Brett Porter [mailto:brett@porterclan.net] On Behalf Of Brett Porter
Sent: Tuesday, May 08, 2012 12:42 AM
To: users@archiva.apache.org
Subject: Re: LDAP authentication

Hi Chris,

Sorry for not catching this thread earlier. I wrote the post on stack overflow, and have several
Archiva instances that meet the 3-point criteria you laid out below. The ticket Mark mentioned
for 1.4 was just to improve the documentation in the next release.

Can you reiterate what config you ended up with and what problem you're having, as it seems
you moved past the ones you initially reported?

To make some observations on earlier points you raised:
- apps/archiva/WEB-INF/classes/org/apache/maven/archiva/security.properties isn't the file
to edit - try conf/security.properties instead (As puppet creates)
- I don't believe you need to edit apps/archiva/WEB-INF/classes/META-INF/plexus/application.xml
either - that can be overridden by properties in security.properties

By containing all the config in the conf directory (which can be stored outside the unpacked
archive if you wish), and backing up the "data" directory which contains the users role database,
you should be able to get a reproducible setup.

- Brett

On 08/05/2012, at 5:17 AM, Chris Jacobs wrote:

> Excellent news. It appears then I'll be waiting for 1.4 to be
> released. :)
>
> I know most projects hate this question but is there a guesstimate when that will happen?
>
> Thanks,
> - chris
>
> -----Original Message-----
> From: mark magallanes [mailto:markjohnmagallanes@gmail.com]
> Sent: Friday, May 04, 2012 12:45 PM
> To: users@archiva.apache.org
> Subject: Re: LDAP authentication
>
> hi i was able to set up archiva with ldap using 1.4-M2 and adding the
> securities.properties file I posted it on this issue
> https://jira.codehaus.org/browse/MRM-1627
>
> so far I am not having any problem with the set-up hope it helps.
>
> Regards
> Mark
>
>
> On Sat, May 5, 2012 at 1:29 AM, Chris Jacobs <Chris.Jacobs@apollogrp.edu>wrote:
>
>> I saw that too, and the linked-to puppet template was quite helpful
>> as well, but I'm still in the same position.
>>
>> Even after the silly process similar the 4th google result, when I
>> login as the admin, I'm taken to the password reset screen which I
>> can still ignore.
>>
>> I'm beginning to think I may not be successful in the the
>> requirements I have for replacing our 'wild-west' archia instance:
>> 1) Configured/managed via puppet
>> 2) Authenticate via LDAP (ssl - which is working)
>> 3) Access site via SSL (should be trivial)
>>
>> When I can not configure the Archiva instance once, and have it work,
>> then I'm unable to satist step 1.
>>
>> Currently I have to do things by hand, using different versions of
>> configs to get things to mostly work.
>>
>> - chris
>>
>> Chris Jacobs
>> Systems Administrator, Technology Services Group
>>
>> Apollo Group  |  Apollo Marketing & Product Development  |  Aptimus, Inc.
>> 1501 4th Ave  |  Suite 2500  |  Seattle, WA 98101 direct 206.839.8245
>> |  cell 206.601.3256  |  Fax 206.644.0628
>> email: chris.jacobs@apollogrp.edu
>>
>> ----- Original Message -----
>> From: Not Zippy <notzippy@gmail.com>
>> To: users@archiva.apache.org <users@archiva.apache.org>
>> Sent: Fri May 04 10:22:36 2012
>> Subject: Re: LDAP authentication
>>
>> I havent tried this but stack overflow has a solution
>>
>> http://stackoverflow.com/questions/8101294/unable-to-get-apache-archi
>> va-working-with-ldap
>>
>> On Fri, May 4, 2012 at 10:14 AM, Chris Jacobs
>> <Chris.Jacobs@apollogrp.edu
>>> wrote:
>>
>>> I am a little disappointed; does no one use Archiva in an
>>> environment where central authentication and disaster recovery is
>>> regarded as
>> important?
>>>
>>> Or perhaps this is the wrong mailing list?
>>>
>>> Or perhaps I'm looking at the wrong documents?
>>>
>>> security.properties file itself offers no hints.
>>> The comments/hints in application.xml seemed to help, but it doesn't
>>> give everything that's needed (apparently).
>>>
>>> A google search for: archiva ldap
>>> 1) http://archiva.apache.org/redback/integration/ldap.html is out of
>> date
>>> with the files being shipped with Archiva.
>>> 2)
>>>
>> https://cwiki.apache.org/ARCHIVA/howto-configure-usermanagement-with-ldap.htmlismissing
the actual useful bits on the page, but talks about them a lot.
>>> 3) An LDAP thread from Oct 2008 on this mailing list talks about a
>>> lack
>> of
>>> documentation, with a broken link to an example default config
>>> (which I managed to trace to the new repo but that didn't help)
>>> 4) A bug report where steps similar to mine are reported but was
>>> closed without addressing the actual issue with the only comment
>>> being "admin account was locked" - but with LDAP enabled there
>>> doesn't appear to be an unlock option.
>>> etc.
>>>
>>> I'm at a loss here; I'm a system administrator - not a dev.
>>>
>>> Anyone feel like giving me some hints?
>>>
>>> - chris
>>>
>>> -----Original Message-----
>>> From: Chris Jacobs [mailto:Chris.Jacobs@apollogrp.edu]
>>> Sent: Thursday, May 03, 2012 4:54 PM
>>> To: users@archiva.apache.org
>>> Subject: RE: LDAP authentication
>>>
>>> I have managed some success by adding the lines to security.properties:
>>>
>>> redback.default.admin=archiva-admin (a real ldap account)
>>> redback.default.guest=archiva-guest (a real ldap account)
>>>
>>> However, if I start with that config form the start, I am unable to
>>> login as the archiva-admin account (even if I set it to other names
>>> which don't exist in LDAP).
>>>
>>> I've found I can work around it by:
>>> Install clean
>>> Add ONLY the redback.default.admin line above Start Archiva Open
>>> page, complete admin form.
>>> On the following ridiculous page, it requests that I now CHANGE the
>>> password.  Pffft.
>>> Stop Archiva
>>> Put in place the security.properties and application.xml files as
>>> below into place - with the addition of the two redback lines above,
>>> and then start archiva.
>>>
>>> And things work.
>>>
>>> Problem: This kind of setup procedure is untenable from a repeatable
>>> system build (disaster recovery is important yo) persepective.
>>>
>>> I suspect that my configs are off somewhere where I'm unable to
>>> login as the archiva-admin LDAP account - if I'm able to resolve
>>> this issue
>> without
>>> having to play config file musical chairs, I'll be golden.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>> - chris
>>>
>>> -----Original Message-----
>>> From: Chris Jacobs [mailto:Chris.Jacobs@apollogrp.edu]
>>> Sent: Thursday, May 03, 2012 11:27 AM
>>> To: users@archiva.apache.org
>>> Subject: LDAP authentication
>>>
>>> Hello,
>>>
>>> The documentation I've seen for configuring authentication via LDAP
>>> is sparse, inconsistent, and out of date (Redback), so before I even
>>> go into the details of my problem I'll grant that I may have missed
>>> something important.
>>>
>>> I'm using the current/latest stable release of Archiva's Standalone,
>> 1.3.5.
>>>
>>> Here are the changes I've made from the default configuration (I
>>> haven't even tried to bring the config and DBs from our existing
>>> 1.2.2 Archiva instance).
>>>
>>> Diff against source of
>>>
>> archiva/apps/archiva/WEB-INF/classes/org/apache/maven/archiva/security.properties:
>>> (cleaned of actual DNS and DN path)
>>> ----------------------------------------------
>>> 28,41d27
>>> <
>>> < ldap.config.hostname=ldap-vip.example.net
>>> < ldap.config.port=389
>>> < ldap.config.base.dn=ou=people,dc=example,dc=net
>>> < ldap.config.context.factory=com.sun.jndi.ldap.LdapCtxFactory
>>> <
>>> < ldap.config.mapper.attribute.email=mail
>>> < ldap.config.mapper.attribute.fullname=cn
>>> < ldap.config.mapper.attribute.password=userPassword
>>> < ldap.config.mapper.attribute.user.id=uid
>>> < ldap.config.mapper.attribute.user.base=ou=people,dc=example,dc=net
>>> < ldap.config.mapper.attribute.user.object.class=inetOrgPerson
>>> <
>>> < ldap.bind.authenticator.enabled=true
>>> ----------------------------------------------
>>>
>>> Diff against source of
>>> archiva/apps/archiva/WEB-INF/classes/META-INF/plexus/application.xml:
>>> (cleaned of actual DNS and DN path)
>>> ----------------------------------------------
>>> 257c257
>>> <     <component>
>>> ---
>>>>    <!-- component>
>>> 266c266
>>> <     </component>
>>> ---
>>>>    </component-->
>>> 291c291
>>> <     <component>
>>> ---
>>>>    <!-- component>
>>> 296,297c296,297
>>> <         <email-attribute>mail</email-attribute>
>>> <         <full-name-attribute>cn</full-name-attribute>
>>> ---
>>>>        <email-attribute>email</email-attribute>
>>>>        <full-name-attribute>givenName</full-name-attribute>
>>> 300c300
>>> <         <user-base-dn>ou=people,dc=example,dc=net</user-base-dn>
>>> ---
>>>>        <user-base-dn>o=com</user-base-dn>
>>> 308c308
>>> <     </component>
>>> ---
>>>>    </component-->
>>> ----------------------------------------------
>>>
>>> I can authenticate as admin just fine, when I authenticate as an
>>> LDAP user, I see in the logs:
>>> ----------------------------------------------
>>> ==> wrapper.20120503.log <==
>>> INFO   | jvm 1    | 2012/05/03 16:34:48 | 2012-05-03 16:34:47.992::WARN:
>>> /archiva/security/login.action
>>> INFO   | jvm 1    | 2012/05/03 16:34:48 | java.lang.NullPointerException
>>> INFO   | jvm 1    | 2012/05/03 16:34:48 |       at
>>>
>> org.codehaus.plexus.redback.struts2.action.LoginAction.webLogin(Login
>> Action.java:341)
>>> INFO   | jvm 1    | 2012/05/03 16:34:48 |       at
>>>
>> org.codehaus.plexus.redback.struts2.action.LoginAction.login(LoginAct
>> ion.java:133)
>>> (continues, snipped)
>>> ----------------------------------------------
>>> ==> archiva.log <==
>>> 2012-05-03 16:34:47,940 [btpool0-3] WARN
>>>
>> org.codehaus.plexus.redback.authentication.users.UserManagerAuthentic
>> ator
>>> - Login for user csjacobs failed. user not found.
>>> 2012-05-03 16:34:47,942 [btpool0-3] INFO
>>> org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticato
>>> r  - Searching for users with filter:
>>> '(&(objectClass=inetOrgPerson)(uid=csjacobs))' from base dn:
>>> ou=people,dc=unix,dc=aptimus,dc=net
>>> 2012-05-03 16:34:47,978 [btpool0-3] INFO
>>> org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticato
>>> r  - Found user?: true
>>> 2012-05-03 16:34:47,980 [btpool0-3] INFO
>>> org.codehaus.plexus.redback.authentication.ldap.LdapBindAuthenticato
>>> r  - Attempting Authenication: +
>> uid=csjacobs,ou=people,dc=unix,dc=aptimus,dc=net
>>> ----------------------------------------------
>>>
>>> And in my browser:
>>> ----------------------------------------------
>>> HTTP ERROR 500
>>>
>>> Problem accessing /archiva/security/login.action. Reason:
>>>
>>>   INTERNAL_SERVER_ERROR
>>> Caused by:
>>>
>>> java.lang.NullPointerException
>>>       at
>>>
>> org.codehaus.plexus.redback.struts2.action.LoginAction.webLogin(Login
>> Action.java:341)
>>>       at
>>>
>> org.codehaus.plexus.redback.struts2.action.LoginAction.login(LoginAct
>> ion.java:133)
>>> (continues, snipped)
>>> ----------------------------------------------
>>>
>>> And most disturbingly, further attempts to to open any page in
>>> archiva results in a similar error, even when I attempt to go to the
>>> logout url directly, but that's due to the account I've attempted to
>>> login as. When
>> I
>>> open archiva in another browser, I can open archiva without difficulty.
>>>
>>> Any information, assistance, etc, would be greatly appreciated.
>>>
>>> Thanks,
>>> - chris
>>>
>>> Chris Jacobs
>>> Systems Administrator, Technology Services Group
>>>
>>> Apollo Group  |  Apollo Marketing & Product Development  |  Aptimus, Inc.
>>> 1501 4th Ave  |  Suite 2500  |  Seattle, WA 98101 direct
>>> 206.839.8245  | cell 206.601.3256  |  Fax 206.644.0628
>>> email: chris.jacobs@apollogrp.edu
>>>
>>>
>>> This message is private and confidential. If you have received it in
>>> error, please notify the sender and remove it from your system.
>>>
>>>
>>>
>>>
>>> This message is private and confidential. If you have received it in
>>> error, please notify the sender and remove it from your system.
>>>
>>>
>>>
>>>
>>> This message is private and confidential. If you have received it in
>>> error, please notify the sender and remove it from your system.
>>>
>>>
>>>
>>
>> This message is private and confidential. If you have received it in
>> error, please notify the sender and remove it from your system.
>>
>>
>>
>
> This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.
>
>

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter
http://twitter.com/brettporter







This message is private and confidential. If you have received it in error, please notify
the sender and remove it from your system.



Mime
View raw message