Skip site navigation (1) Skip section navigation (2)

Re: Seeking experiences 'accessing' Microsoft Active Directory credentials from PostgreSQL, in conjunction with the sys admin / IT...

From: Jasen Betts <jasen(at)xnet(dot)co(dot)nz>
To: pgsql-novice(at)postgresql(dot)org
Subject: Re: Seeking experiences 'accessing' Microsoft Active Directory credentials from PostgreSQL, in conjunction with the sys admin / IT...
Date: 2010-02-24 10:45:07
Message-ID: hm2vvj$tvi$1@reversiblemaps.ath.cx (view raw or flat)
Thread:
Lists: pgsql-novice
On 2010-02-24, Michael Wood <esiotrot(at)gmail(dot)com> wrote:
> On 24 February 2010 07:56, Bret S. Lambert <bret(dot)lambert(at)gmail(dot)com> wrote:
> [...]
>>> *     A 'direct' read-only connection (without comprising the network
>>> security), but of what sort? I have no experience in how AD stores and
>>> shares its info, bit am happy to learn what is needed (IT has a lot of
>>> knowledge of course, but don't use PostgreSQL)
>>
>> The most straightforward solution would be for postgres to grab the
>> data via an LDAP connection (that's how AD exports data) after getting
>> set up by your admins to get read-only access to the user data you need.
>>
>> However, I'm not sure that postgres has the code to pull in LDAP
>> data as a table (which would be a nice feature, IMO), but doing a
>> daily/hourly/every 30 seconds/whenever cron job which pulls data
>> via a ldapsearch (I'm assuming unix, because, frankly, I don't
>> care about windows), and then rebuilds a table with the new data.
>
> I wonder if you couldn't do this with e.g. a plperl function or something?

yes, it should be possible to do a set returning plperl or C functuion
which querys the AD via LDAP and use that function to populate a view

not very efficient (if queried frequently) but reasonably seamless.


In response to

pgsql-novice by date

Next:From: Atif JungDate: 2010-02-24 11:56:59
Subject: Migration from INFORMIX to POSTGRESQL
Previous:From: A. KretschmerDate: 2010-02-24 09:15:23
Subject: Re: Need help with update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group