Rudder

<dovrak_> .o/

<dovrak_> has anyone here had success with ldap auth in rudder? (I'm with a team here trying to deploy a non-production rudder environment for test purposes ... we've hit a brick wall with authentication)

<dovrak_> or perhaps a better question: how do you deal with authentication in rudder?

<ncharles> Hi

<dovrak_> hey :)

<ncharles> rudder use spring security

<ncharles> the default implementation is a XML user file (which is not great)

<dovrak_> yeah - we've been hunting through (rather aimlessly - we're very ignorant!) through the spring documentation for hints

<dovrak_> yeah

<dovrak_> we found the rudder "if you're really sure you want to test this" page :D

<ncharles> :)

<dovrak_> and followed that - and it isn't authenticating against XML any more ... but it's not authenticating against our LDAP server either. We're not sure if any log output is generated either?

<dovrak_> any hints / suggestions / slaps-in-the-face would be very appreciated :D

<ncharles> i'm looking for clues for your questions

<ncharles> did you read http://www.rudder-project.org/rudder-doc-2.6/rudder-doc.html#user-management ?

<ncharles> ha, this is the if you really want to test this ?

<ncharles> so, in the XML part, you define the authentication

<ncharles> i'm browsing the code to check for logs

<ncharles> hum

<Vince_Macbuche> Hi dovrak_

<ncharles> first, you can set your logging to debug or trace, by modifying the file /opt/rudder/etc/logback.xml

<dovrak_> ncharles: Yeah, we read through 9.1.4: "If you are operating on a corporate..."

<dovrak_> Vince_Macbuche: Heyo :)

<ncharles> there you have a <root level="info"> that you can change to <root level="debug"> or <root level="trace"> to help you track what is happening

<ncharles> (you'll need to restart the rudder webapp afterward)

<dovrak_> sir, you are a scholar and a gentleman!

<ncharles> logs are in /var/log/rudder/webapps

<dovrak_> we saw some start-up info in those logs - didn't have a clue how to make them more verbose!

<dovrak_> ty!

* dovrak_ prods

<dovrak_> dunno how we missed that, we grepped about for logging options ...

<dovrak_> maybe we were in the webapps dir

* alag has quit (Quit: Leaving.)

<ncharles> and I guess the version of the JAR referenced in the docsare not the correct ones :(

* alag (~alag@stc92-1-82-227-107-99.fbx.proxad.net) has joined

<ncharles> it shouldn't be 3.0.5.RELEASE but 3.1.0.RELEASE (if you are using Rudder 2.6)

<dovrak_> hmm, ok

<dovrak_> I'll update those too!

* dovrak_ goes to grab coffee

<dovrak_> brb

<dnns> dovrak_: your name is almost like a keyboard layout :P

<ncharles> or a musician :)

<dnns> :)

* Kegeruneku feels a disturbance in the sysadmin force

<Kegeruneku> LDAP...

<Kegeruneku> Invocation complete

<Kegeruneku> Om nom nom

* keytab has quit (Quit: Konversation terminated!)

* keytab (~isma@23.Red-80-34-194.staticIP.rima-tde.net) has joined

<dovrak_> dnns: I think it captures several things, 1: that my usual nick (wally) is already registered, 2: that I'm into things like weird keyboard layouts, 3: I'm completely dyslexic :D

<dnns> dovrak_: lol :D

<dnns> general question.. i've updated rudder-server-root, and now i'm upgrading my rudder-agents..

<dnns> is it somehow possible to see which nodes altready got the upgrade and which not - without ssh-ing to the nodes

<dnns> ?

<ncharles> with the inventory ?

<dovrak_> ncharles: I've increased the log levels ... <root level="trace"> <logger name="org.springframework" level="trace" />

<dovrak_> ncharles: And there is now DEBUG entries in /var/log/rudder/webapp/2013_08_12.stderrout.log.*

<dovrak_> but nothing when I try to login to rudder

<dovrak_> (for example)

<dovrak_> not a squeak out of it

<dovrak_> (oh and I switched to 3.1.0-RELEASE for the spring lib

<ncharles> and on the ldap side, do you see the incomming connexions ?

<dnns> ncharles: so by clicking them one by one? would be a nice to have in the search criteria

<dovrak_> ncharles: I see a few packets flowing. I'll pull them up in wireshark, take a closer look.

<Kegeruneku> I'm interested.

<Kegeruneku> Normally, you should see a bind request

<ncharles> dnns: a query that search software by name and version ?

<dovrak_> ncharles: Good shout. I need to sleep :D There's indeed a bind request, followed by a rseultCode: invalidCredentials

<dovrak_> ncharles: I know very little about LDAP - I'm guessing it's failing to auth against the LDAP server to perform the search? (I tried to enable "anonymousReadOnly" - perhaps that's not allowed/incorrect)

<dovrak_> the client (rudder) sent an "authentication: simple"

<dovrak_> with what I'd guess is a password hash

<ncharles> dovrak_: Kegeruneku should be able to help you more than I could

<ncharles> (i'm not that good in ldap)

<dovrak_> sorry - I'm so knackered

<dovrak_> I'm misreading usernames

<ncharles> don't be !

<dovrak_> Kegeruneku: as above :) Thank you both!

<ncharles> you're welcome :)

<dovrak_> :)

<Kegeruneku> dovrak_: Normally, rudder should authenticate using the "simple" method (meaning: non SASL), trying to provide the login and a password hash

<Kegeruneku> Hm

<dovrak_> Kegeruneku: I'm wondering if it's our LDAP schema ... I have a feeling we had issues getting it to work with RH6 recently ...

<dovrak_> Kegeruneku: I'm *completely* ignorant to LDAP, so this may be a total red herring - our arrangement is: ou=Users,dc=ldap,dc=local

<dnns> ncharles: that's a good idea, only i have to wait then - inventories are not sent yet :)

<Kegeruneku> dovrak_: Easy to test, try from the rudder server: /opt/rudder/bin/ldapwhoami -x -D "<your bind DN>" -W

<dovrak_> and a user has a common name of "Firstname Lastname", and a uid (property?) of username

<Kegeruneku> Ok, so ...

<Kegeruneku> dovrak_: Easy to test, try from the rudder server: /opt/rudder/bin/ldapwhoami -x -D "uid=dovrak,ou=Users,dc=ldap,dc=local" -W

<Kegeruneku> It should ask you for the password, and answer with your user DN if everything went OK

<dovrak_> invalid credentials (49)

<Kegeruneku> Oops

<Kegeruneku> I forgot something

<dovrak_> :D

<Kegeruneku> /opt/rudder/bin/ldapwhoami -x -D "uid=dovrak,ou=Users,dc=ldap,dc=local" -W -H ldap.host.name :D

<dovrak_> same response

<Kegeruneku> (ldap://blabla/ for example)

<dovrak_> yeah

<Kegeruneku> Strange, I tested it on our own LDAP.

<Kegeruneku> Hm...

<dovrak_> possibly of interest:

<dovrak_> if I do -D "cn=Matthew Hall,...etc..."

<dovrak_> it works

<dovrak_> I have a feeling it relates to something weird in our LDAP setup

<dovrak_> /opt/rudder/bin/ldapwhoami -x -D "cn=Matthew Hall,ou=Users,dc=ldap,dc=local" -W -H ldap://xxx

<Kegeruneku> I'm looking to see if there is something we can do in the properties file for this

<Kegeruneku> Found

<Kegeruneku> <beans:list><beans:value>uid={0},ou=people</beans:value></beans:list>

<Kegeruneku> Should be <beans:list><beans:value>cn={0},ou=people</beans:value></beans:list>

<Kegeruneku> So you can use CNs

<dovrak_> username becomes full name?

<Kegeruneku> Yeah

<dovrak_> i.e. <firstname> <lastname> (in our case0?

<dovrak_> ok

<Kegeruneku> I'm not really sure it will work, but in theory...

* dovrak_ makes a note to ask someone to improve our LDAP setup ... lol

<Kegeruneku> Ha ha

<dovrak_> you know when you look at something with complete ignorance, yet your guy says "that just doesn't look right..."?

<Kegeruneku> And I'm trying to see with our local RBAC guru how will Rudder behave with users in LDAP concerning privileges

<dovrak_> the way we've identified everyone uniquely by firname_lastname just didn't sit right with me lol

<Kegeruneku> I see :D

<Kegeruneku> Vince_Macbuche: ?

<Kegeruneku> Halp

* Vince_Macbuche appears

<dovrak_> user-search-filter?

<dovrak_> Kegeruneku: That logs me in, and then straight out :D

<dovrak_> Kegeruneku: Authorisation fial?

* dovrak_ checks his group settings

* You are now known as dovrak

-NickServ- This nickname is registered. Please choose a different nickname, or identify via /msg NickServ identify <password>.

>NickServ< identify ****

-NickServ- You are now identified for dovrak.

<Kegeruneku> Actually, this documentation has been tested before we had authorization levels in Rudder

<Kegeruneku> that is what i wanted to discuss with Vince_Macbuche

<Kegeruneku> I don't know what level it would use by default

<dovrak> it logs in for sure, then immediately redirects back to the login page

<Vince_Macbuche> the default value would be no rights ... I'm look how to configure it

<dovrak> thanks guys :)

<dovrak> *sigh* ... pen-test meeting

<dovrak> bbs

* Kegeruneku tests his pen

<Kegeruneku> <click>

<Kegeruneku> Working perfectly, test over.

<dnns> Kegeruneku: :P

* ade_b has quit (Quit: Too sexy for his shirt)

<dovrak> :D

<dovrak> is it likely I'm being bumped out after login due to Rudder not knowing what group(s) I'm in?

<dovrak> the authentication seems to be working like a champ - (with the minor exception of it using CNs rather than UIDs - which is clearly due to our LDAP setup here)

<fanf> dovrak: yeah... I think we missed a mapping for LDAP between user and rights...

<dovrak> ok

<coredumb> Messieurs - dames bien le bonjour

<dovrak> is there a CLI ldap command of awesome that?ll validate the group configuration?

<fanf> hello coredumb

<fanf> dovrak: I don't think so, that's a missing part in the code

<fanf> humpf

<Vince_Macbuche> dovrak: I'm still looking about a workaround for your usecase, but i think it will need some fixes in Rudder to make it work (need a mapper from LDAP to specific User configuration )

<dovrak> ok, that?s fair enough :)

<dovrak> is there a way we can adjust our usercase?

<dovrak> is there a simple change we can make to our ldap tree to make it play nice?

<dovrak> or a recommended alternative way of using Rudder? (i.e. offload the authentication to the webserver or something)

<fanf> dovrak: I don't think, it's really an overlooking from us...

<dovrak> ok

<fanf> well, you could still - for testing only - generate an xml file from you LDAP users, but that would means other password for Rudder, not really good

<dovrak> if I exported (i.e. daily) the ldap tree, could I extract the password hashes from ldap?

<dovrak> straight into the xml file?

<Kegeruneku> ldap uses salted SHA passwords by default

<Kegeruneku> Can we use them in Rudder ?

<dovrak> if we can, and someone can point me in the right direction for reading ldap info, I?m happy to hack up a bit of perl ;-)

<fanf> well, we won't have the salt

<dovrak> when in doubt, call perl via cron lol

<fanf> :)

<fanf> the pass can be hashed in md5, sha, sha256, sha512 - but if they are salted, we won't have the salt

<fanf> humpf

<fanf> dovrak: for me, it's a bug - could you open an issue for version 2.6 ?

<fanf> I will see how to make it work

<dovrak> fanf: absolutely!

<dovrak> fanf: how would you like this phrased? This is an inability for Rudder to authorise users based via LDAP, resulting in the user being immediately logged out?

<fanf> that seems ok, yes

<fanf> thanks