First thanks for the plugin, that's exactly what I need :-) Had a quick look at your plugin and checked out the latest version from SVN and installed it in my WordPress installation.
My local OpenLDAP server here does not allow anonymous bind, according to the doc and to the config page I couldn't figure out a way to specify a bind user and a bind password. Is that possible already or would I have to hack that myself?
And am I right that the Account Filter is simply the field used for usernames so it will restrict the search just for that field right? That would be uid in my case then.
You can refer to the dev thread the ticket points to to hack it in for now if you want, but it will be addressed in the codebase too soon. The person who launched the thread is on vacation, so I was waiting for him to come back before working on it so he could test, but we could work on it together in the meantime if you're willing.
For the Account Filter part, it's the field used to locate the user's profile after successful login. Other plugins and libraries default to samAccountName, so I stuck to the same, but in my case, it's on userPrincipalName. Essentially, it has to be a field that contains the exact same value that the user enter in the login form.
> First thanks for the plugin, that's exactly what I need :-) Had a > quick look at your plugin and checked out the latest version from SVN > and installed it in my WordPress installation.
> My local OpenLDAP server here does not allow anonymous bind, according > to the doc and to the config page I couldn't figure out a way to > specify a bind user and a bind password. Is that possible already or > would I have to hack that myself?
> And am I right that the Account Filter is simply the field used for > usernames so it will restrict the search just for that field right? > That would be uid in my case then.
> soon. The person who launched the thread is on vacation, so I was > waiting for him to come back before working on it so he could test, > but we could work on it together in the meantime if you're willing.
Sure, I got quite some experience debugging LDAP stuff so no problem for me :-) I also did code PHP LDAP interfaces so I think we should get somewhere together.
> For the Account Filter part, it's the field used to locate the user's > profile after successful login. > Other plugins and libraries default to samAccountName, so I stuck to > the same, but in my case, it's on userPrincipalName. > Essentially, it has to be a field that contains the exact same value > that the user enter in the login form.
ok, I don't use AD but OpenLDAP so that would be the uid field for me.
> [...] >> soon. The person who launched the thread is on vacation, so I was >> waiting for him to come back before working on it so he could test, >> but we could work on it together in the meantime if you're willing.
> Sure, I got quite some experience debugging LDAP stuff so no problem > for me :-) I also did code PHP LDAP interfaces so I think we should > get somewhere together.
Kick a**. One more use case soon to be solved. :)
I'm exhausted tonight and will take a break from it all, but I'll get back to you shortly.
>> For the Account Filter part, it's the field used to locate the user's >> profile after successful login. >> Other plugins and libraries default to samAccountName, so I stuck to >> the same, but in my case, it's on userPrincipalName. >> Essentially, it has to be a field that contains the exact same value >> that the user enter in the login form.
> ok, I don't use AD but OpenLDAP so that would be the uid field for me.
I'm fairly sure it is.
re: AD: that's what I have at work, but I'm probably going to set myself up an instance of OpenLDAP under Fedora to have my own sandbox for that. But nothing beats other people with real life production test beds (and more LDAP admin experience). :)
But rather than confusing the potential future support group users, would you mind "meeting" me at the development group instead? We can follow up on the existing related thread. Just read the 2 last comments, which resume where we're at. The last one, I'll add now for you to reply to if you find the time.
> > [...] > >> soon. The person who launched the thread is on vacation, so I was > >> waiting for him to come back before working on it so he could test, > >> but we could work on it together in the meantime if you're willing.
> > Sure, I got quite some experience debugging LDAP stuff so no problem > > for me :-) I also did code PHP LDAP interfaces so I think we should > > get somewhere together.
> Kick a**. One more use case soon to be solved. :)
> I'm exhausted tonight and will take a break from it all, but I'll get > back to you shortly.
> >> For the Account Filter part, it's the field used to locate the user's > >> profile after successful login. > >> Other plugins and libraries default to samAccountName, so I stuck to > >> the same, but in my case, it's on userPrincipalName. > >> Essentially, it has to be a field that contains the exact same value > >> that the user enter in the login form.
> > ok, I don't use AD but OpenLDAP so that would be the uid field for me.
> I'm fairly sure it is.
> re: AD: that's what I have at work, but I'm probably going to set > myself up an instance of OpenLDAP under Fedora to have my own sandbox > for that. But nothing beats other people with real life production > test beds (and more LDAP admin experience). :)
> But rather than confusing the potential future support group users, > would you mind "meeting" me at the development group instead? We can > follow up on the existing related thread. Just read the 2 last > comments, which resume where we're at. The last one, I'll add now for > you to reply to if you find the time.
> On Sep 10, 8:26 pm, Stephane Daury <stephane.da...@gmail.com> wrote:> On Sep 10, 2007, at 14:13, ktk wrote:
> > > Hey Stephane,
> > > [...] > > >> soon. The person who launched the thread is on vacation, so I was > > >> waiting for him to come back before working on it so he could test, > > >> but we could work on it together in the meantime if you're willing.
> > > Sure, I got quite some experience debugging LDAP stuff so no problem > > > for me :-) I also did code PHP LDAP interfaces so I think we should > > > get somewhere together.
> > Kick a**. One more use case soon to be solved. :)
> > I'm exhausted tonight and will take a break from it all, but I'll get > > back to you shortly.
> > >> For the Account Filter part, it's the field used to locate the user's > > >> profile after successful login. > > >> Other plugins and libraries default to samAccountName, so I stuck to > > >> the same, but in my case, it's on userPrincipalName. > > >> Essentially, it has to be a field that contains the exact same value > > >> that the user enter in the login form.
> > > ok, I don't use AD but OpenLDAP so that would be the uid field for me.
> > I'm fairly sure it is.
> > re: AD: that's what I have at work, but I'm probably going to set > > myself up an instance of OpenLDAP under Fedora to have my own sandbox > > for that. But nothing beats other people with real life production > > test beds (and more LDAP admin experience). :)
> On Sep 11, 7:07 pm, Stephane Daury <stephane.da...@gmail.com> wrote:
> > Alright, let's tackle this thing! :)
> > But rather than confusing the potential future support group users, > > would you mind "meeting" me at the development group instead? We can > > follow up on the existing related thread. Just read the 2 last > > comments, which resume where we're at. The last one, I'll add now for > > you to reply to if you find the time.
> > On Sep 10, 8:26 pm, Stephane Daury <stephane.da...@gmail.com> wrote:> On Sep 10, 2007, at 14:13, ktk wrote:
> > > > Hey Stephane,
> > > > [...] > > > >> soon. The person who launched the thread is on vacation, so I was > > > >> waiting for him to come back before working on it so he could test, > > > >> but we could work on it together in the meantime if you're willing.
> > > > Sure, I got quite some experience debugging LDAP stuff so no problem > > > > for me :-) I also did code PHP LDAP interfaces so I think we should > > > > get somewhere together.
> > > Kick a**. One more use case soon to be solved. :)
> > > I'm exhausted tonight and will take a break from it all, but I'll get > > > back to you shortly.
> > > >> For the Account Filter part, it's the field used to locate the user's > > > >> profile after successful login. > > > >> Other plugins and libraries default to samAccountName, so I stuck to > > > >> the same, but in my case, it's on userPrincipalName. > > > >> Essentially, it has to be a field that contains the exact same value > > > >> that the user enter in the login form.
> > > > ok, I don't use AD but OpenLDAP so that would be the uid field for me.
> > > I'm fairly sure it is.
> > > re: AD: that's what I have at work, but I'm probably going to set > > > myself up an instance of OpenLDAP under Fedora to have my own sandbox > > > for that. But nothing beats other people with real life production > > > test beds (and more LDAP admin experience). :)
