.o/ 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) or perhaps a better question: how do you deal with authentication in rudder? Hi hey :) rudder use spring security the default implementation is a XML user file (which is not great) yeah - we've been hunting through (rather aimlessly - we're very ignorant!) through the spring documentation for hints yeah we found the rudder "if you're really sure you want to test this" page :D :) 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? any hints / suggestions / slaps-in-the-face would be very appreciated :D i'm looking for clues for your questions did you read http://www.rudder-project.org/rudder-doc-2.6/rudder-doc.html#user-management ? ha, this is the if you really want to test this ? so, in the XML part, you define the authentication i'm browsing the code to check for logs hum Hi dovrak_ first, you can set your logging to debug or trace, by modifying the file /opt/rudder/etc/logback.xml ncharles: Yeah, we read through 9.1.4: "If you are operating on a corporate..." Vince_Macbuche: Heyo :) there you have a that you can change to or to help you track what is happening (you'll need to restart the rudder webapp afterward) sir, you are a scholar and a gentleman! logs are in /var/log/rudder/webapps we saw some start-up info in those logs - didn't have a clue how to make them more verbose! ty! * dovrak_ prods dunno how we missed that, we grepped about for logging options ... maybe we were in the webapps dir * alag has quit (Quit: Leaving.) 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 it shouldn't be 3.0.5.RELEASE but 3.1.0.RELEASE (if you are using Rudder 2.6) hmm, ok I'll update those too! * dovrak_ goes to grab coffee brb dovrak_: your name is almost like a keyboard layout :P or a musician :) :) * Kegeruneku feels a disturbance in the sysadmin force LDAP... Invocation complete Om nom nom * keytab has quit (Quit: Konversation terminated!) * keytab (~isma@23.Red-80-34-194.staticIP.rima-tde.net) has joined 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 dovrak_: lol :D general question.. i've updated rudder-server-root, and now i'm upgrading my rudder-agents.. is it somehow possible to see which nodes altready got the upgrade and which not - without ssh-ing to the nodes ? with the inventory ? ncharles: I've increased the log levels ... ncharles: And there is now DEBUG entries in /var/log/rudder/webapp/2013_08_12.stderrout.log.* but nothing when I try to login to rudder (for example) not a squeak out of it (oh and I switched to 3.1.0-RELEASE for the spring lib and on the ldap side, do you see the incomming connexions ? ncharles: so by clicking them one by one? would be a nice to have in the search criteria ncharles: I see a few packets flowing. I'll pull them up in wireshark, take a closer look. I'm interested. Normally, you should see a bind request dnns: a query that search software by name and version ? ncharles: Good shout. I need to sleep :D There's indeed a bind request, followed by a rseultCode: invalidCredentials 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) the client (rudder) sent an "authentication: simple" with what I'd guess is a password hash dovrak_: Kegeruneku should be able to help you more than I could (i'm not that good in ldap) sorry - I'm so knackered I'm misreading usernames don't be ! Kegeruneku: as above :) Thank you both! you're welcome :) :) dovrak_: Normally, rudder should authenticate using the "simple" method (meaning: non SASL), trying to provide the login and a password hash Hm Kegeruneku: I'm wondering if it's our LDAP schema ... I have a feeling we had issues getting it to work with RH6 recently ... Kegeruneku: I'm *completely* ignorant to LDAP, so this may be a total red herring - our arrangement is: ou=Users,dc=ldap,dc=local ncharles: that's a good idea, only i have to wait then - inventories are not sent yet :) dovrak_: Easy to test, try from the rudder server: /opt/rudder/bin/ldapwhoami -x -D "" -W and a user has a common name of "Firstname Lastname", and a uid (property?) of username Ok, so ... dovrak_: Easy to test, try from the rudder server: /opt/rudder/bin/ldapwhoami -x -D "uid=dovrak,ou=Users,dc=ldap,dc=local" -W It should ask you for the password, and answer with your user DN if everything went OK invalid credentials (49) Oops I forgot something :D /opt/rudder/bin/ldapwhoami -x -D "uid=dovrak,ou=Users,dc=ldap,dc=local" -W -H ldap.host.name :D same response (ldap://blabla/ for example) yeah Strange, I tested it on our own LDAP. Hm... possibly of interest: if I do -D "cn=Matthew Hall,...etc..." it works I have a feeling it relates to something weird in our LDAP setup /opt/rudder/bin/ldapwhoami -x -D "cn=Matthew Hall,ou=Users,dc=ldap,dc=local" -W -H ldap://xxx I'm looking to see if there is something we can do in the properties file for this Found uid={0},ou=people Should be cn={0},ou=people So you can use CNs username becomes full name? Yeah i.e. (in our case0? ok I'm not really sure it will work, but in theory... * dovrak_ makes a note to ask someone to improve our LDAP setup ... lol Ha ha you know when you look at something with complete ignorance, yet your guy says "that just doesn't look right..."? And I'm trying to see with our local RBAC guru how will Rudder behave with users in LDAP concerning privileges the way we've identified everyone uniquely by firname_lastname just didn't sit right with me lol I see :D Vince_Macbuche: ? Halp * Vince_Macbuche appears user-search-filter? Kegeruneku: That logs me in, and then straight out :D 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 . >NickServ< identify **** -NickServ- You are now identified for dovrak. Actually, this documentation has been tested before we had authorization levels in Rudder that is what i wanted to discuss with Vince_Macbuche I don't know what level it would use by default it logs in for sure, then immediately redirects back to the login page the default value would be no rights ... I'm look how to configure it thanks guys :) *sigh* ... pen-test meeting bbs * Kegeruneku tests his pen Working perfectly, test over. Kegeruneku: :P * ade_b has quit (Quit: Too sexy for his shirt) :D is it likely I'm being bumped out after login due to Rudder not knowing what group(s) I'm in? 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) dovrak: yeah... I think we missed a mapping for LDAP between user and rights... ok Messieurs - dames bien le bonjour is there a CLI ldap command of awesome thatīll validate the group configuration? hello coredumb dovrak: I don't think so, that's a missing part in the code humpf 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 ) ok, thatīs fair enough :) is there a way we can adjust our usercase? is there a simple change we can make to our ldap tree to make it play nice? or a recommended alternative way of using Rudder? (i.e. offload the authentication to the webserver or something) dovrak: I don't think, it's really an overlooking from us... ok 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 if I exported (i.e. daily) the ldap tree, could I extract the password hashes from ldap? straight into the xml file? ldap uses salted SHA passwords by default Can we use them in Rudder ? 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 ;-) well, we won't have the salt when in doubt, call perl via cron lol :) the pass can be hashed in md5, sha, sha256, sha512 - but if they are salted, we won't have the salt humpf dovrak: for me, it's a bug - could you open an issue for version 2.6 ? I will see how to make it work fanf: absolutely! 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? that seems ok, yes thanks