Kenneth

Thanks for that. However, it doesn't work. For one, even if it could
work, it would break configurable failover, as an attempt is being made
to select the individual instance directly with a regex match. So if
that particular LDAP server were to fail, the request would most likely
fail. 

However, I tried it anyway, to see what it does. It doesn't work. I
think FR does not know what autz-type to choose; reports that no
password was found for the user.

Tarun

-----Original Message-----
From: Kenneth Grady [mailto:[EMAIL PROTECTED]
Sent: Thursday, 7 October 2004 11:54 PM
To: Tarun Bhushan
Subject: RE: Selecting correct LDAP instance (long)


how about
        autztype ldap-basic {
           redundant {
                ldap1-basic <---
                ldap2-basic
           }
        }
        autztype ldap-special {
           redundant {
                ldap1-special
                ldap2-special
           }
        }

(note: the =~)

DEFAULT Client-IP-Address == 10.19.16.33, autz-type =~ "ldap.-special",
LDAP-Group == "ra-special", Auth-Type := Local
        Fall-Through = No
DEFAULT Client-IP-Address == 10.19.26.16, autz-type =~ "ldap.-basic",
LDAP-Group == "ra-basic", Proxy-To-Realm := 'tokenserver'
        Fall-Through = No

also in rediusd.conf change the ldap1 to ldap1-basic and ldap2



On Wed, 2004-10-06 at 17:26, Tarun Bhushan wrote:
> I had noted this and saw that during module instantiation, a per
> instance ldap_groupcmp is registered. However, this is done for each
> separate individual instance. In my case, where I have two pairs of
> redundant blocks (eg. in the authorize section):
> 
>         autztype ldap-basic {
>            redundant {
>                 ldap1
>                 ldap2
>            }
>         }
>         autztype ldap-special {
>            redundant {
>                 ldap1-special
>                 ldap2-special
>            }
>         }
> 
> I would expect to see a ldap_groupcmp registered to the higher levels
> (ldap-basic and ldap-special) rather than it what it really does -
> registers ldap_groupcmp to each of the lower levels (ldap1, ldap2 and
> ldap1-special, ldap2-special). Because of the latter behaviour, how do
I
> then nominate a per instance LDAP-Group attribute to use in the
'users'
> file, as the DEFAULT statements in the latter have to be at a higher
> level (as shown below), to make configurable failover work:
> 
> DEFAULT Client-IP-Address == 10.19.16.33, autz-type := ldap-special,
> LDAP-Group == "ra-special", Auth-Type := Local
>         Fall-Through = No
> DEFAULT Client-IP-Address == 10.19.26.16, autz-type := ldap-basic,
> LDAP-Group == "ra-basic", Proxy-To-Realm := 'tokenserver'
>         Fall-Through = No
> 
> What would I choose as the LDAP-Group attribute in each of the above
two
> statements, considering that the instantiations register four separate
> ldap_groupcmp functions corresponding to four separate LDAP-Group
> attributes (as shown in the DEBUG extracts below)?
> 
> rlm_ldap: Registering ldap_groupcmp for Ldap-Group
> rlm_ldap: Creating new attribute ldap1-Ldap-Group
> rlm_ldap: Registering ldap_groupcmp for ldap1-Ldap-Group
> rlm_ldap: Registering ldap_xlat with xlat_name ldap1
> <snip>
> rlm_ldap: Registering ldap_groupcmp for Ldap-Group
> rlm_ldap: Creating new attribute ldap2-Ldap-Group
> rlm_ldap: Registering ldap_groupcmp for ldap2-Ldap-Group
> rlm_ldap: Registering ldap_xlat with xlat_name ldap2
> <snip>
> rlm_ldap: Registering ldap_groupcmp for Ldap-Group
> rlm_ldap: Creating new attribute ldap1-special-Ldap-Group
> rlm_ldap: Registering ldap_groupcmp for ldap1-special-Ldap-Group
> rlm_ldap: Registering ldap_xlat with xlat_name ldap1-special
> <snip>
> rlm_ldap: Registering ldap_groupcmp for Ldap-Group
> rlm_ldap: Creating new attribute ldap2-special-Ldap-Group
> rlm_ldap: Registering ldap_groupcmp for ldap2-special-Ldap-Group
> rlm_ldap: Registering ldap_xlat with xlat_name ldap2-special
> <etc>
> 


NOTICE
This e-mail and any attachments are confidential and may contain copyright material of 
Macquarie Bank or third parties. If you are not the intended recipient of this email 
you should not read, print, re-transmit, store or act in reliance on this e-mail or 
any attachments, and should destroy all copies of them. Macquarie Bank does not 
guarantee the integrity of any emails or any attached files. The views or opinions 
expressed are the author's own and may not reflect the views or opinions of Macquarie 
Bank.


-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html

Reply via email to