Re: PAM LDAP CREATE USER - Mailing list pgsql-general
| From | Aaron_Wright@selinc.com |
|---|---|
| Subject | Re: PAM LDAP CREATE USER |
| Date | |
| Msg-id | OF74FE20F4.25A99373-ON88257EEA.007BD9B4-88257EEA.007E702D@selinc.com Whole thread Raw |
| In response to | Re: PAM LDAP CREATE USER (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-general |
> From: Tom Lane <tgl@sss.pgh.pa.us>
> Aaron_Wright@selinc.com writes:
> > I recently upgraded from 8.4 to 9.3, and my custom LDAP PAM module no
> > longer works.
>
> 8.4.what and 9.3.what?
8.4.16 to 9.3.4
> Have you checked the behavior in any other releases?
Not yet. I was interested in getting a laugh test from the mailing list first; to see if I was completely off my rocker or not.
> > In brief, my LDAP PAM module authenticates a centralized user and then
> > creates a matching database user, using a separate super user connection
> > to the database, before returning successfully from the PAM module. This
> > used to work beautifully, but now I get a FATAL error, "role %s does not
> > exist".
>
> That seems mighty Rube Goldbergian
From what I've researched this is the only way to accomplish what I'm trying to. Everything I read online keeps telling me that in order for LDAP to work with postgresql, the user must already exist in the database. Most of the workarounds for this, involve a cron job that sucks up the entire directory of users and creates matching users in the database periodically.
That seems a little crazy to me, so I have a PAM LDAP module which creates the users on the fly.
> ... but it's not clear why it used to
> work and doesn't anymore. If you'd said 9.4 I'd have guessed at a corner
> case in catalog snapshot invalidation, but I think 9.3 would just be
> looking for the role with SnapshotNow, which should pretty much always
> work. (You're sure the transaction in the background is getting committed
> in time, right? And it's being sent to the 9.3 DB not the 8.4 one?)
The PAM LDAP module uses PQconnectdb to create a super user connection to the database. It uses PQexec to run "CREATE USER 'user' PASSWORD NULL IN ROLE 'role';". And finishes up with a PQfinish before PAM_SUCCESS is returned to postgres. I'm a bit limited in my database knowledge, so please let me know if that sequence is leaving something dangling. I see the "CREATE USER" query in the pg_log file.
Also, if I try to log in a second time, it works fine. This is presumably because the user now exists.
> Also, just to clarify: this is a PAM auth module that just happens to talk
> to some LDAP server behind the scenes, right? If Postgres thinks this is
> LDAP auth method then some other possibilities open up --- but AFAICS
> we've not touched the PAM code since 8.4.2.
You're correct, this is a PAM auth module that handles talking to the LDAP server and authenticating the user.
pg_hba.conf line includes "host all all 0.0.0.0/0 pam pamservice=..." and there's a matching pam configuration file.
I'm not familiar with the "LDAP auth method", but I don't think I can use that as the documents say, "user must already exist" in that situation, which is the same problem I'm trying to fix.
> regards, tom lane
> Aaron_Wright@selinc.com writes:
> > I recently upgraded from 8.4 to 9.3, and my custom LDAP PAM module no
> > longer works.
>
> 8.4.what and 9.3.what?
8.4.16 to 9.3.4
> Have you checked the behavior in any other releases?
Not yet. I was interested in getting a laugh test from the mailing list first; to see if I was completely off my rocker or not.
> > In brief, my LDAP PAM module authenticates a centralized user and then
> > creates a matching database user, using a separate super user connection
> > to the database, before returning successfully from the PAM module. This
> > used to work beautifully, but now I get a FATAL error, "role %s does not
> > exist".
>
> That seems mighty Rube Goldbergian
From what I've researched this is the only way to accomplish what I'm trying to. Everything I read online keeps telling me that in order for LDAP to work with postgresql, the user must already exist in the database. Most of the workarounds for this, involve a cron job that sucks up the entire directory of users and creates matching users in the database periodically.
That seems a little crazy to me, so I have a PAM LDAP module which creates the users on the fly.
> ... but it's not clear why it used to
> work and doesn't anymore. If you'd said 9.4 I'd have guessed at a corner
> case in catalog snapshot invalidation, but I think 9.3 would just be
> looking for the role with SnapshotNow, which should pretty much always
> work. (You're sure the transaction in the background is getting committed
> in time, right? And it's being sent to the 9.3 DB not the 8.4 one?)
The PAM LDAP module uses PQconnectdb to create a super user connection to the database. It uses PQexec to run "CREATE USER 'user' PASSWORD NULL IN ROLE 'role';". And finishes up with a PQfinish before PAM_SUCCESS is returned to postgres. I'm a bit limited in my database knowledge, so please let me know if that sequence is leaving something dangling. I see the "CREATE USER" query in the pg_log file.
Also, if I try to log in a second time, it works fine. This is presumably because the user now exists.
> Also, just to clarify: this is a PAM auth module that just happens to talk
> to some LDAP server behind the scenes, right? If Postgres thinks this is
> LDAP auth method then some other possibilities open up --- but AFAICS
> we've not touched the PAM code since 8.4.2.
You're correct, this is a PAM auth module that handles talking to the LDAP server and authenticating the user.
pg_hba.conf line includes "host all all 0.0.0.0/0 pam pamservice=..." and there's a matching pam configuration file.
I'm not familiar with the "LDAP auth method", but I don't think I can use that as the documents say, "user must already exist" in that situation, which is the same problem I'm trying to fix.
> regards, tom lane
pgsql-general by date: