On 16 Aug 2015, at 11:44, Zeus Panchenko <zeus@ibs.dn.ua> wrote:
Alan DeKok <aland@deployingradius.com> wrote:
User-Profile is not assigned?
Because it doesn't assign User-Profile when doing LDAP group checks.
so, am I wrong to expect User-Profile assignment in case the user is the member of Ldap_Group, when `users' file contains that DEFAULT definition?
DEFAULT Ldap-Group == ..., User-Profile := ...
or, is it the only way to get User-Profile assigned according the Ldap-Group membership, to:
post-auth { if (LDAP-Group == "LDAP Group One") { User-Profile := "cn=userprofile1,ou=profiles,ou=RADIUS,dc=xyz" } }
then how is it correct to assign the profile? is syntax above correct?
That documentation wasn't updated for v3.0.x unfortunately. user.default is a polymorphic config item in v3.0.x, meaning it can be an attribute reference a literal string or an exec. If you wanted to use it you'd set user.default to &control:User-Profile, e.g. ldap { user { default = &control:User-Profile } } And set the profile in the users file, just as you appear to be trying to do. It may be that the users file is updating the request atomically, so that both control and reply items get added in such a way that one cannot reference the other, which is why your expansion %{control:LDAP-Profile} appears to be an empty string. I'd try listing debug_control after calling the users file and seeing if the value for User-Profile appears there. authorize { files debug_control ldap } If debug_control doesn't exist add the following to raddb/policy.conf # # Outputs the contents of the control list in debugging (-X) mode # debug_control { if("%{debug_attr:control:}" == '') { noop } } -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2