Jump to content


Perforce LDAP integration


  • Please log in to reply
5 replies to this topic

#1 ITSupport-ORTEC

ITSupport-ORTEC

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 26 February 2019 - 09:21 AM

Hi,

We are going to use LDAP authentication in Perforce. We have set out the following steps that we will take in our upcoming maintenance weekend. We are not actually sure if this approach is good enough.
  • The server security level will be raised to 3. (P4 configure set security=3)

  • p4 ldap config1
    Name: config1
    Host: ADServer1
    Port: 636Encryption: ssl
    BindMethod: sasl
    Options: nodowncase nogetattrs norealminusername
    SearchScope: subtree
    GroupSearchScope: subtree
    p4 ldap config2
    Name: config2
    Host:

    ADServer

    2
    Port: 636
    Encryption: ssl
    BindMethod: sasl
    Options: nodowncase nogetattrs norealminusername
    SearchScope: subtree
    GroupSearchScope: subtree


  • We will test the authentication
    (p4 ldap -t username config1)

    (p4 ldap -t username config2)



  • We will set configurables
    (P4 configure set auth.ldap.order.1=config1)

    (P4 configure set auth.ldap.order.1=config2)


Do we have to use the command p4 configure set auth.default.method=ldap? We want to change the authentication method for users in phases, and not with a bing bang (everyone at the same time). Is this even possible?


#2 p4rfong

p4rfong

    Advanced Member

  • Staff Moderators
  • 310 posts

Posted 27 February 2019 - 02:19 AM

Looks good, but try the "p4 ldap -t <username> config1" to make sure it works now.
You can run "p4 configure set auth.default.method=perforce" so new users will use perforce authentication instead of ldap.

#3 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 164 posts
  • LocationSan Francisco, CA

Posted 08 March 2019 - 12:11 AM

We recently made the same change.

The good news is that our LDAP system forces 'strong' passwords already. The bad news was that we had some service accounts that had weak passwords, so on the first switchover attempt most of our automation broke.

We had to go through all our service accounts and ensure they had strong passwords, then ran with 'security=3' for a while before we made the switch.

One other thing to keep in mind is that perhaps you have service accounts that are not in LDAP. We did (all of them.) So before you switch, into each non-LDAP user and manually, explicitly set:

AuthMethod:    perforce

This will override any configurables that set the default auth method to LDAP. We happened to go all at once with everybody, so on cutover day we essentially just had to flip 'auth.default.method' from 'perforce' to 'ldap' and that was that.

Another tact for doing this in phases is to explicitly set all users to "AuthMethod: perforce", then turn on LDAP as the default. This will essentially only create new users as LDAP and everyone else will stay on perforce. Then you can flip individual users to "AuthMethod: ldap" at your leisure.

Frankly, that seems like a lot of work to me, though (we're right around 850 human users.) After our first service account flub and correcting that, on cutover day we had near zero problems, except for the folks that didn't read their email and we had to remind them to use their LDAP user/password. But from a technical standpoint, no problems whatsoever since then.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com

#4 Chris Makin

Chris Makin

    Newbie

  • Members
  • Pip
  • 2 posts

Posted 19 March 2019 - 05:52 PM

:lol: "except for the folks that didn't read their email and we had to remind them to use their LDAP user/password. But from a technical standpoint, no problems whatsoever since then." This mirrors our experience of shifting to LDAP auth exactly.

#5 ITSupport-ORTEC

ITSupport-ORTEC

    Newbie

  • Members
  • Pip
  • 9 posts

Posted 28 March 2019 - 12:44 PM

@everyone that reacted,

Thanks for all your replies.



We raised the server security level to 3 and are phasing out peforce authentication in batches of 50 perforce accounts a time.

There is one other thing that I would like to ask. Some of my colleagues (4 people) have a perforce accountname that is not equal to their domain account name.
The rights in the depots are set with p4 protects What command should I issue to change the perforce account names in p4 protects? After that I can finally change their authentication method.
(script or command).

#6 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 164 posts
  • LocationSan Francisco, CA

Posted 03 April 2019 - 06:37 AM

View PostITSupport-ORTEC, on 28 March 2019 - 12:44 PM, said:

@everyone that reacted,

Thanks for all your replies.


We raised the server security level to 3 and are phasing out peforce authentication in batches of 50 perforce accounts a time.

There is one other thing that I would like to ask. Some of my colleagues (4 people) have a perforce accountname that is not equal to their domain account name.
The rights in the depots are set with p4 protects What command should I issue to change the perforce account names in p4 protects? After that I can finally change their authentication method.
(script or command).


I'm not sure when it was introduced, pretty recently, but there is a new-ish "p4 rename user" command that will do all the magic for you. If you don't have that command available due to your p4d version being too old, it's worth looking at the man page for it so you can see all the things you'll have to change manually (or probably scripturally):

https://www.perforce...l#p4_renameuser

I've had a perl script doing this 'reown' process for a decade and a half. It was a good run but I can retire it now.
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users