Prev: bwidget listbox -selectmode multple had a bind missing
Next: Scriptics writeup for wikipedia needed
From: rfransix on 30 Apr 2010 16:14
Hi,

While binding to LDAP and searching on an attribute value, I can't see
to find/get the needed attribute value in the person's record and
return the result to a mapped field (mapped to the original searched
on attribute).

Anyone done this, been there? Care to share the one liner?

Thanks.
From: Cyan on 3 May 2010 06:18
On Apr 30, 10:14 pm, rfransix <rfran...(a)comcast.net> wrote:
> Hi,
>
> While binding to LDAP and searching on an attribute value, I can't see
> to find/get the needed attribute value in the person's record and
> return the result to a mapped field (mapped to the original searched
> on attribute).
>
> Anyone done this, been there? Care to share the one liner?
>
> Thanks.

Not sure I follow you, but I use code like the following all the time
to extract info from the LDAP interface to Novell's eDirectory:

set ldap [ldap::connect $host]
ldap::bind $ldap $bind_dn $bind_pw ;# Major gotcha here is that if
bind_pw is "" you get an anonymous bind, even if $bind_dn doesn't
exist
foreach result [ldap::search $ldap $base_dn
"(objectClass=something)" {someAttribute} -scope sub] {
lassign $result dn attribs
puts "someAttribute for ($dn) is: \"[lindex [dict get $attribs
someAttribute] 0]\"" ;# lindex ... 0 to get the first value, almost
always what you want unless someAttribute is multivalue
}

Some things to be careful of (might only apply to the eDirectory / AD
implementations):

1. The RFCs specify nasty behaviour if the bind password is blank -
the bind succeeds, even if the user specified doesn't exist. Bites
hard if you just do a bind to do password checking. Always check the
password is not blank, or turn off anonymous binds in the backend.

2. Check that permissions don't restrict the user you're binding as
from reading the attribute you want

3. Be careful about case sensitivity issues

Cyan
From: rfransix on 3 May 2010 16:05
On May 3, 5:18 am, Cyan <cyan.ogil...(a)gmail.com> wrote:
> On Apr 30, 10:14 pm, rfransix <rfran...(a)comcast.net> wrote:
>
> > Hi,
>
> > While binding to LDAP and searching on an attribute value, I can't see
> > to find/get the needed attribute value in the person's record and
> > return the result to a mapped field (mapped to the original searched
> > on attribute).
>
> > Anyone done this, been there? Care to share the one liner?
>
> > Thanks.
>
> Not sure I follow you, but I use code like the following all the time
> to extract info from the LDAP interface to Novell's eDirectory:
>
> set ldap  [ldap::connect $host]
> ldap::bind $ldap $bind_dn $bind_pw    ;# Major gotcha here is that if
> bind_pw is "" you get an anonymous bind, even if $bind_dn doesn't
> exist
> foreach result [ldap::search $ldap $base_dn
> "(objectClass=something)" {someAttribute} -scope sub] {
>     lassign $result dn attribs
>     puts "someAttribute for ($dn) is: \"[lindex [dict get $attribs
> someAttribute] 0]\""    ;# lindex ... 0 to get the first value, almost
> always what you want unless someAttribute is multivalue
>
> }
>
> Some things to be careful of (might only apply to the eDirectory / AD
> implementations):
>
> 1. The RFCs specify nasty behaviour if the bind password is blank -
> the bind succeeds, even if the user specified doesn't exist.  Bites
> hard if you just do a bind to do password checking.  Always check the
> password is not blank, or turn off anonymous binds in the backend.
>
> 2. Check that permissions don't restrict the user you're binding as
> from reading the attribute you want
>
> 3. Be careful about case sensitivity issues
>
> Cyan

On May 3, 5:18 am, Cyan <cyan.ogil...(a)gmail.com> wrote:
> On Apr 30, 10:14 pm, rfransix <rfran...(a)comcast.net> wrote:
>
> > Hi,
>
> > While binding to LDAP and searching on an attribute value, I can't see
> > to find/get the needed attribute value in the person's record and
> > return the result to a mapped field (mapped to the original searched
> > on attribute).
>
> > Anyone done this, been there? Care to share the one liner?
>
> > Thanks.
>
> Not sure I follow you, but I use code like the following all the time
> to extract info from the LDAP interface to Novell's eDirectory:
>
> set ldap [ldap::connect $host]
> ldap::bind $ldap $bind_dn $bind_pw ;# Major gotcha here is that if
> bind_pw is "" you get an anonymous bind, even if $bind_dn doesn't
> exist
> foreach result [ldap::search $ldap $base_dn
> "(objectClass=something)" {someAttribute} -scope sub] {
> lassign $result dn attribs
> puts "someAttribute for ($dn) is: \"[lindex [dict get $attribs
> someAttribute] 0]\"" ;# lindex ... 0 to get the first value, almost
> always what you want unless someAttribute is multivalue
>
> }
>
> Some things to be careful of (might only apply to the eDirectory / AD
> implementations):
>
> 1. The RFCs specify nasty behaviour if the bind password is blank -
> the bind succeeds, even if the user specified doesn't exist. Bites
> hard if you just do a bind to do password checking. Always check the
> password is not blank, or turn off anonymous binds in the backend.
>
> 2. Check that permissions don't restrict the user you're binding as
> from reading the attribute you want
>
> 3. Be careful about case sensitivity issues
>
> Cyan

Thanks for the reply Cyan,

The standard for our org is not the same as your example, we use code
like this...

bind -prot ldapv3 -addr myldapserver:389 -us
{cn=Admin,cn=SystemDomain} -pa {secret} -au simple -bindid tmpbind
....
code goes here
....
unbind tmpbind

The process fails saying "Unknown argument "tmpbind"."

Thanks again.
 | 
Pages: 1
Prev: bwidget listbox -selectmode multple had a bind missing
Next: Scriptics writeup for wikipedia needed