|
<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
|