Jump to content


Perforce LDAP integration


  • Please log in to reply
3 replies to this topic

#1 ITSupport-ORTEC

ITSupport-ORTEC

    Newbie

  • Members
  • Pip
  • 6 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
  • 299 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
  • 144 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 Today, 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.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users