Using ldap_xlat in unlang with Chars not allowed in an ldap search

[Phil Mayers]

On 29/08/12 16:00, Daniel Finger wrote:

> If I have searched correctly it should work if I rewrite the Attribute with
> \28 for ( and \29 for ) (as ascii string, not escaped :-))

Shouldn't that be %28 and %29? Relevant docs here are RFC 4516 section 
2.1, which references RFC 3986 section 2.1.

>
> As it seems the rewrite Module is not the solution as i could not get it to
> do this :-)
>
> It works as I expected it to do if the CommonName does not contain the
> Parentheses.
> Any Ideas to work around these Parentheses? Preferably using any Char
> allowed in the Common Name, as i expect it to contain Umlauts or an & Char.

There's no easy way to do this with the built-in LDAP code. When the 
"xlat" is called, it's called with one big string i.e. the un-escaped 
value is already inside the string, and can't be escaped.

Maybe there's room for an xlat in the server core:

%{urlquote:%{Value}}

...which might be generally useful.

In the meantime, you can probably emulate this with rlm_perl - define a 
simple perl module:

perl urlquote {
   module = ${confdir}/urlquote.pl
   func_xlat = xlat
}

...and in "urlquote.pl"

use strict;
use URI::Escape;

sub xlat {
   my $input = shift;
   return uri_escape($input);
}

...then use the xlat like this:

  Attr := "%{ldap:....?cn=%{urlquote:%{TLS-Client-...}}?...}