Project

General

Profile

Bug #3829 ยป rudder_irc.txt

IRC convo on the subject - Matthew Hall, 2013-08-12 18:05

 
<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
    (1-1/1)