Posted 16 December 2013 - 10:24 PM
I have followed the manual instructions to link authentication to the AD server, but it doesn't completely work. I have the test script (commons_auth_check.sh) working and returning 0 when I provide the correct credentials. I have added the line in the triggers (exact same as in the manual). I can add a user, using the "p4 -u mjoanis user -o"... then I can login with that user in the shell as well as using the Commons web interface (I have a standard OVA installation, a few days old). The problem is that it doesn't require any password at all. I see nothing in the logs, though maybe I'm not looking at the right place. I need some help with this. I don't know what to do at this point. Why isn't it authenticating the user against the AD server?
Posted 16 December 2013 - 11:16 PM
'p4 configure show security'
Did you put a backdoor into your auth_check.sh script? So if you do turn on AD (uses security level 3), you don't lock yourself out.
!!!Big Big warning, if you lock yourself out you have to jump through some hoops to have your perforce server usable again.
Posted 17 December 2013 - 01:02 AM
# p4 -u commonssuper triggers // yields a file with lots of comments, then these 3 lines: Triggers: CPU form-save group "bash /usr/local/bin/commons_protection_updater.sh %formname% %user%" AUTH auth-check auth "/bin/bash /usr/local/bin/commons_auth_check.sh %user%" # p4 -u commonssuper configure show security // Does nothing at all.
I didn't set a backdoor... I'm guessing it's a user that you should hardcode directly in the script. I assume I can always go back and edit the script when needed. Tell me if I'm wrong. I'm very new to Perforce administration (usage as well).
Thanks for your help,
Posted 17 December 2013 - 01:36 AM
Posted 18 December 2013 - 05:29 AM
Posted 18 December 2013 - 05:22 PM
Posted 18 December 2013 - 06:25 PM
mjoanis@MJoanis-PC:~$ ssh firstname.lastname@example.org email@example.com's password: Welcome to Ubuntu 12.04.3 LTS (GNU/Linux 3.5.0-42-generic x86_64) * Documentation: [url="https://help.ubuntu.com/"]https://help.ubuntu.com/[/url] Last login: Mon Dec 16 19:51:53 2013 from 192.168.100.53 root@localhost:~# p4 triggers -o You don't have permission for this operation. root@localhost:~# su perforce perforce@localhost:/root$ p4 triggers -o You don't have permission for this operation. perforce@localhost:/root$ exit exit root@localhost:~# p4 -u commonssuper triggers -o Your session has expired, please login again. root@localhost:~# p4 -u commonssuper login Enter password: User commonssuper logged in. root@localhost:~# p4 triggers -o You don't have permission for this operation. root@localhost:~# p4 -u commonssuper triggers -o # Perforce Submit and Form Validating Trigger Specifications. # # Triggers: a list of triggers; one per line. Each trigger line must be # indented with spaces or tabs in the form. Each line has four # elements: # # Name: The name of the trigger. # # Type: 'archive' external archive access triggers # 'auth-check' check authentication trigger # 'auth-check-sso' sso check authentication trigger # 'auth-set' set authentication trigger # 'change-submit' pre-submit triggers # 'change-content' modify content submit triggers # 'change-commit' post-submit triggers # 'fix-add' pre-add fix triggers # 'fix-delete' pre-delete fix triggers # 'form-in' modify form in triggers # 'form-out' modify form out triggers # 'form-save' pre-save form triggers # 'form-commit' post-save form triggers # 'form-delete' pre-delete form triggers # 'service-check' check auth trigger (service users) # 'shelve-submit' pre-shelve triggers # 'shelve-commit' post-shelve triggers # 'shelve-delete' pre-delete shelve triggers # # Path: For change-* or shelve-*triggers, a pattern to # match files in the changelist. # # For form-* triggers, the type of form: e.g. 'branch' # 'client', etc. # # For fix-* triggers use 'fix'. # # For auth-* triggers use 'auth'. # # For archive triggers, a file pattern to match the # file name being accessed. # # Command: The OS command to run for validation. If the # command contains spaces, the whole command must # be quoted. See 'p4 help triggers' for a list of # variables that can be expanded in the command # string. # # For example, # # Triggers: # example change-submit //depot/... "cmd %changelist%" # # See 'p4 help triggers' for more information about triggers. Triggers: CPU form-save group "bash /usr/local/bin/commons_protection_updater.sh %formname% %user%" AUTH auth-check auth "/bin/bash /usr/local/bin/commons_auth_check.sh %user%" root@localhost:~#
It doesn't show above, but there's a '\t' before "CPU" and before "AUTH".
Posted 18 December 2013 - 10:15 PM
Can you give me a sample user name from your system? You can mangle it slightly, but I'm curious to see if there are - or ' ' in it.
Posted 18 December 2013 - 10:45 PM
if test $result = 32
I think you need to change that to:
if test $result = 0
Please let me know if that works. If it does I'll ask our doc team to add a section on how to get the proper value for your system.
Posted 19 December 2013 - 10:00 PM
- I tried the 0 vs 32 test, and it stopped working when I put 0. So that wasn't it.
- The usernames are all matching "^[a-z]+$", i.e. only ASCII lower case letters, like mjoanis, aeinstein, mcurie, etc.
Here it goes:
What I did on the server so far:
// deployed from OVA VM 2013.5.72.9202 // set static IP using the web admin interface # apt-get update # apt-get install emacs23-nox ldap-utils locate // uncommented section for AD without SSL // uncommented the COMMONSMGMTPASS line too # emacs /etc/p4d.conf > authHostURL="ldap://192.168.100.3:389" > authBase="CN=servers,OU=CIENAME,DC=domCIENAME,DC=local" > authDomain="USERID_HERE@domCIENAME.local" // edited /etc/profile as I thought fit to use local p4 client # emacs /etc/profile > export P4PORT=localhost:1666 > export P4USER=perforce > export P4CHARSET=utf8 > export P4EDITOR=emacs # source /etc/profile // I saw that P4JOURNAL, P4LOG, P4PORT, and P4ROOT are defined in /etc/p4d.conf // Should I redefine P4JOURNAL and P4LOG in profile? Which ones should I redefine in profile? # commons_auth_check.sh mj (good password) // doesn't work, as expected, because of wrong username # commons_auth_check.sh mjoanis (good password) # echo $? 0 // works! # commons_auth_check.sh mjoanis (wrong password) # echo $? 1 // doesn't work # emacs `which commons_auth_check.sh` // changed 32 for 0 in the $result test // made commons_auth_check.sh worse... it failed to authenticate with even correct credentials
So above is what I had before I deleted the users I created in p4 and recreating them to demonstrate from "nothing". Then, the following happened:
// // Testing authentication // # p4 users commonsadmin <firstname.lastname@example.org> (commonsadmin) accessed 2013/12/19 commonsguest <email@example.com> (commonsguest) accessed 2013/10/23 commonsmgmt <firstname.lastname@example.org> (commonsmgmt) accessed 2013/10/23 commonssuper <email@example.com> (commonssuper) accessed 2013/12/19 perforce <perforce@localhost> (perforce) accessed 2013/12/19 root <root@localhost> (root) accessed 2013/12/16 # commons_auth_check.sh mjoanis (good password) # echo $? 0 // as expected # commons_auth_check.sh mj (password) Invalid user and/or password // as expected # p4 -u mjoanis user -o Perforce password (P4PASSWD) invalid or unset. # p4 users commonsadmin <firstname.lastname@example.org> (commonsadmin) accessed 2013/12/19 commonsguest <email@example.com> (commonsguest) accessed 2013/10/23 commonsmgmt <firstname.lastname@example.org> (commonsmgmt) accessed 2013/10/23 commonssuper <email@example.com> (commonssuper) accessed 2013/12/19 mjoanis <mjoanis@localhost> (mjoanis) accessed 2013/12/19 perforce <perforce@localhost> (perforce) accessed 2013/12/19 root <root@localhost> (root) accessed 2013/12/16 // good, mjoanis is in the list now, but why isn't it using the email from AD? # p4 -u mjoanis login Enter password: (wrong password) Password invalid. 'AUTH' validation failed: Invalid user and/or password // good! refused by 'AUTH' # p4 -u mjoanis login Enter password: (good password) User mjoanis logged in. // great! 'AUTH' trigger works??? // attempting login on Commons web interface // it refused with wrong password // it refused with no password // it accepted with right user // // I don't get it. // // What's different from the last attempt is that I commented the exports for // P4JOURNAL and P4LOG from /etc/profile
I have tried with another user, and I just had to 'p4 -u username -o' and she got access with AD authentication and everything looks fine. I'm lost. Happy it works, yet frustrated because, for all I know, it might as well stop working tomorrow morning.
So, other than removing P4JOURNAL and P4LOG from /etc/profile, I didn't change much. I deleted and recreated users, but I did that many times the other day too.
One thing you can tell the documentation team, though, is that their command line
p4 -u <USERID>user -o ## Ignore the error message(found http://www.perforce..../DB5-51842.html, in the PDF version, and maybe in some other places)
needs a space before 'user'. Before I understood more clearly p4's syntax and possible commands, I wondered if it was not a copy-paste byproduct, some convention by which you always add 'user' at the end of your usernames, or something else. It obviously gave me errors, but as they say to ignore the error message...... I did.
For the record, the error message to be expected is (at least that's what I've got)
Perforce password (P4PASSWD) invalid or unset.I'm wondering if fooling around with the many possibilities might not have prevented it from working sooner...
Now, the questions (some of them have also been asked somewhere above):
- Could have P4JOURNAL and/or P4LOG had an effect on this?
- I did set P4PORT, P4USER, P4CHARSET, and P4EDITOR in /etc/profile. If I set P4JOURNAL and P4LOG, will they only affect the client, or are they going to modify the logging behavior of the server too?
- Is it normal that the user email (p4 -u mjoanis user mjoanis) is set to "mjoanis@localhost", and not what can be found in the LDAP?
I'm almost tempted to create a new server just to see if didn't forget anything in my procedures... That might happen after the holidays...
Thank you very much for your help!
Posted 19 December 2013 - 10:41 PM
1) Neither P4JOURNAL nor P4LOG could have affected the ability to login. At least nothing that I can think of, and having been a QA person on the server, I can think of a lot.
2) I think those variables are sourced from a script for the Perforce server. I can double check.
3) Yes, user@machine name is the default value for the email field. The Commons trigger is not written to source the real email address from LDAP. Come to think of it, I don't think our other LDAP trigger is either. More thorough integration with LDAP/AD is likely something we will be taking a look at in the future.
Posted 20 December 2013 - 03:28 PM
2) They are assigned and exported at the end of /etc/p4d.conf ... I don't know well enough how these variables are managed to tell, but I was afraid that I would override something if I did set them in /etc/profile too. They are clearly set in that script, yet if I type "echo $P4LOG", I get nothing. So... either the script isn't run like I think it should, or there are namespaces for environment variables? I don't know what I'm talking about here.
3) The ability to fetch user details from an LDAP directory is a clear advantage. DRY principle!
Also tagged with one or more of these keywords: ad, ldap, ova, auth
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users