ActiveDirectory authentication - trigger doesn't work?

c:\Program Files\Perforce>p4 triggers
You don't have permission for this operation.

c:\Program Files\Perforce>p4 -u commonssuper triggers -o
Access for user 'commonssuper' has not been enabled by 'p4 protect'.

c:\Program Files\Perforce>p4 -u gqyu triggers -o
You don't have permission for this operation.

 

– when p4 jobspce , p4 trigger then below message printed.

You don’t have permission for this operation.
>>  you need right perforce user account that has permission.

ex) p4 -u {p4userid} -P {password} {command}

 

http://forums.perforce.com/index.php?/topic/2970-activedirectory-authentication-trigger-doesnt-work/

 

Hello,

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?

Thanks,

MJ

#2 phopkins

Advanced Member

  • Members
  • PipPipPip
  • 88 posts

Posted 16 December 2013 - 11:16 PM

First thing is what is your output from.
'p4 triggers'
and
'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.

#3 MJoanis

Newbie

  • Members
  • Pip
  • 8 posts

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

#4 P4Matt

Advanced Member

  • Staff
  • 1352 posts

Posted 17 December 2013 - 01:36 AM

The times I've locked myself out in the past I've done just that; modify the trigger to let anyone in so you can get in and fix it.

#5 MJoanis

Newbie

  • Members
  • Pip
  • 8 posts

Posted 18 December 2013 - 05:29 AM

Is there any more relevant information I could provide to resolve the situation? I did follow the guide and got the auth script to work. Maybe there's an issue with the triggers?

#6 P4Matt

Advanced Member

  • Staff
  • 1352 posts

Posted 18 December 2013 - 05:22 PM

Can you share your trigger entries? If you can run the auth script successfully from the command line, there must be, as you suggest, an issue with the triggers. I just need the output of 'p4 triggers -o'.

#7 MJoanis

Newbie

  • Members
  • Pip
  • 8 posts

Posted 18 December 2013 - 06:25 PM

That's what I included in the code section of my second email. I'll show you including comments and user rights. Maybe the problem is some user right thing too..?! I left the default users there, I changed the least possible amount of parameters to make it easy to repeat and debug when required. Here's the full thing:

mjoanis@MJoanis-PC:~$ ssh root@192.168.100.14
root@192.168.100.14'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".

Thanks!

#8 P4Matt

Advanced Member

  • Staff
  • 1352 posts

Posted 18 December 2013 - 10:15 PM

I'm in the process of setting up a test environment. One quick thing to check: does commons_auth_check.sh correctly reject a bad login? The trigger entries look kosher, so I'm currently at a bit of a loss. I'm going to look through the code and see if anything stands out.

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.

#9 P4Matt

Advanced Member

  • Staff
  • 1352 posts

Posted 18 December 2013 - 10:45 PM

Nevermind all that, I've figured out the issue; different LDAP servers give different return codes when a user is in the system or not. In 'commons_auth_check.sh' you'll find a line that reads:

 
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.

#10 MJoanis

Newbie

  • Members
  • Pip
  • 8 posts

Posted 19 December 2013 - 10:00 PM

I'm really confused right now...
  • 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.
The thing is... it works fine right now. I was working on assembling a detailed description of what I did since the server installation, and when I got to demonstrate that the authentication doesn't work, it just worked. I'll still paste below what I did, and ask a few questions afterwards.

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 <commonsadmin@localhost.localdom> (commonsadmin) accessed 2013/12/19
commonsguest <commonsguest@localhost.localdom> (commonsguest) accessed 2013/10/23
commonsmgmt <commonsmgmt@localhost.localdom> (commonsmgmt) accessed 2013/10/23
commonssuper <commonssuper@localhost.localdom> (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 <commonsadmin@localhost.localdom> (commonsadmin) accessed 2013/12/19
commonsguest <commonsguest@localhost.localdom> (commonsguest) accessed 2013/10/23
commonsmgmt <commonsmgmt@localhost.localdom> (commonsmgmt) accessed 2013/10/23
commonssuper <commonssuper@localhost.localdom> (commonssuper) accessed 2013/12/19mjoanis <mjoanis@localhost> (mjoanis) accessed 2013/12/19perforce <perforce@localhost> (perforce) accessed 2013/12/19root <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 loginEnter password: (wrong password)Password invalid.'AUTH' validation failed: Invalid user and/or password// good! refused by 'AUTH'# p4 -u mjoanis loginEnter 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!

MJ

#11 P4Matt

Advanced Member

  • Staff
  • 1352 posts

Posted 19 December 2013 - 10:41 PM

I'm glad to hear it's working although I'm equally dismayed that it magically started working. :)

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.

#12 MJoanis

Newbie

  • Members
  • Pip
  • 8 posts

Posted 20 December 2013 - 03:28 PM

1) Thanks, that's what I supposed!

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! :)

Thanks again,
MJ

posted @ 2015-04-28 15:39  alxe_yu  阅读(276)  评论(0)    收藏  举报