RE: [sec: unclas] Huntgroupname checkitem in LDAP
Van: freeradius-users-
[EMAIL PROTECTED]
[mailto:freeradius-users-
[EMAIL PROTECTED] Namens
Ranner,
Frank MR
Verzonden: dinsdag 17 oktober 2006 4:17
Aan: FreeRadius users mailing list
Onderwerp: RE: [sec: unclas] Huntgroupname checkitem in LDAP
DEFAULT Ldap-Group == `%{Huntgroup-Name}`
Access-Level := RW,
Service-Type = Administrative-User,
Cisco-AVPair := shell:priv-lvl=15,
Passport-Command-Impact = configuration
Although this approach Works if you just want to add attributes for a
certain huntgroup if a user is member of it.
My problem is, I have 2 user databases, one being SQL the other being
LDAP/AD
I want to be able to specify to which NASses the LDAP/AD user has access
too.
If it were only LDAP/AD users, everything would work like this:
DEFAULT Ldap-Group == `%{Huntgroup-Name}`
Fall-Through = no
DEFAULT Auth-Type := REJECT
In this way, every user that is not a member of a specific Group that
matches a Huntgroup name is denied access.
But I still have the SQL users and the above rules breaks them.
So I changed it to this:
DEFAULT SQL-Group == `%{Huntgroup-Name}`
Fall-Through = no
DEFAULT Ldap-Group == `%{Huntgroup-Name}`
Fall-Through = no
DEFAULT Auth-Type := REJECT
In this way, I need to change my SQL users setup from instead having the
Huntgroup-Name in SQL as a checkitem (radgroupcheck) to add every SQL
user to a SQL-group having the same name as the huntgroup.
This behaviour works but is not really desirable.
After searching and experimenting the trick to NOT break EAP/LDAP/SQL
but still having everything working like I wanted it to be was just as
follows:
DEFAULT Ldap-Group == `%{Huntgroup-Name}`
Fall-Through = no
DEFAULT Auth-Type = LOCAL
Fall-Through = Yes
This configuration allows for the default SQL behaviour to stay the
same, having EAP AND locking Ldap users to the NASes controlled by there
groupmembership. Since I spent a long time figuring this out I wanted to
share this to the list.
My current setup has SQL users + Complete Active Directory integration
(having EAP=NTLM) + LDAP(PAP/etc...)
Kind Regards,
J.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Huntgroupname checkitem in LDAP
Hello, im looking for a way to have my huntgroups defined in LDAP similar to the way they are in SQL. For example if a user belongs to Ldap-Group vpn, the Group in ldap contains an attribute containing the huntgroup names which the Group gives access to. I tried adding checkItem Huntgroup-Name info to my ldap.attrmap with attribute info having value: =~ ^(vpn|sslvpn)$ (without succes) I had success with the following setup: In users: DEFAULT Huntgroup-Name == vpn, Ldap-Group == vpn Fall-Through = no DEFAULT Huntgroup-Name == sslvpn, Ldap-Group == sslvpn Fall-Through = no DEFAULT Auth-Type := Reject This allows to specify which user has access to which nasgroup by adding groupmemberships to the user. But it breaks the users existing in SQL. I could off course also add the specific SQL-Groups into the users file but this would still require a reorganisation of the SQL users since they only have a Huntgroup-Name attribtue for there grouplevel which specifies multiple huntgroups by using regexp. Im kinda stuck in how to implement it. Any advice would be greatly appreciated. J. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: [sec: unclas] Huntgroupname checkitem in LDAP
I have been experimenting with something like this and
found you can (mis)use the hints file to do something like
this:
DEFAULT Hint
=
`%{ldap:ldap:///ou=hosts,dc=demo,dc=org?radiusHuntgroupName?one?ipHostNumber=%{NAS-IP-Address}}`
If you want you can use Huntgroup-Name insttead of hint. in
that case, you should add a default, otherwise Huntgroup-Name
gets set to "".
DEFAULT
Huntgroup-Name =
`%{ldap:ldap:///ou=hosts,dc=demo,dc=org?radiusHuntgroupName?one?ipHostNumber=%{NAS-IP-Address}:-None}`
In this case, Huntgroup-Name
gets set to None if it isn't found in ldap.
Some
caveats:
The huntgroup file will not
be processed if Huntgroup-Name exists already. Since hints is processed before
huntgroups that will be the
case.
Hints does not implement
fallthrough - you get one match only. If you want to process usernames too,
instantiate another instance.
Another approach I have used
is similar to your solution. i used rules in users like
this:
DEFAULT Ldap-Group ==
`%{Huntgroup-Name}` Access-Level
:= RW, Service-Type =
Administrative-User, Cisco-AVPair
:= "shell:priv-lvl=15",
Passport-Command-Impact = configuration
The huntgroups are defined
in the huntgroups file, or could be defined as above; users are put into groups
corresponding to the huntgroup names.
You can also generate pseudo
groups like this:
DEFAULT Ldap-Group ==
`%{Huntgroup-Name}_RO`
Access-Level := RO, Service-Type =
Nas-Prompt-User
So a user in radius group
sydney_RO gets Readonly access to devices in huntgroup
sydney
For this to work you need to
apply a patch I submitted in the list some time ago, otherwise the substitution
works only once.
regards
Frank
Ranner
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
On Behalf Of Jonathan De GraeveSent: Tuesday, 17 October 2006
01:18To: freeradius-users@lists.freeradius.orgSubject:
Huntgroupname checkitem in LDAP
Hello, im looking for a way to
have my huntgroups defined in LDAP similar to the way they are in
SQL.
For example if a user belongs to
Ldap-Group vpn, the Group in ldap contains an attribute containing the
huntgroup names which the Group gives access to.
I tried adding checkItem
Huntgroup-Name info to my ldap.attrmap with attribute info having value:
=~ ^(vpn|sslvpn)$ (without succes)
I had success with the following
setup:
In
users:
DEFAULT Huntgroup-Name == vpn,
Ldap-Group == vpn
Fall-Through = no
DEFAULT Huntgroup-Name == sslvpn,
Ldap-Group == sslvpn
Fall-Through = no
DEFAULT Auth-Type :=
Reject
This allows to specify which user
has access to which nasgroup by adding groupmemberships to the user. But it
breaks the users existing in SQL.
I could off course also add the
specific SQL-Groups into the users file but this would still require a
reorganisation of the SQL users since they only have a Huntgroup-Name
attribtue for there grouplevel which specifies multiple huntgroups by using
regexp.
Im kinda stuck in how to
implement it. Any advice would be greatly
appreciated.
J.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
