RE: optimize questions for unlang code
Am 06.04.2012 18:16, schrieb Brian Julin: Tobias Hachmer wrote: Q3: Is there a smarter way to reject an AD user immediately when he wants to logon to a telnet device? You could use Auth-Type subsections, but with LDAP the control flow can be a bit confusing (the statements in the block outside those sections all run, and then the block gets run again from the top once an Auth-Type is selected, which happens inside of the ldap module.) Your best bet for this scenario is to look at the "as of 2.0" instructions in clients.conf, where you can select a virtual server to enter based on which clients are requesting, and construct a separate virtual server for telnet devices. Wow, thank you Brian for your good answer. I know virtual servers and I don't knwo why this idea didn't come to me, maybe a mental block. I have implemented this immediately and looks fine know. Thanks again! Q4: Are there any tweaking capabilities to my unlang code to make it smarter or more hardened? Q5: Can I abbreviate any code snippets like using a switch/case block or use variables or anything I don't know? When using Ldap-Group as a check item, you have to be careful, because it is a special case. You are not really comparing the value after the '==' to a variable, rather each time an LDAP group query is launched looking for the value after the '=='. This is the way LDAP groups work -- you do not query a list of groups, you query them one-by-one. Note that using Ldap-Group in the "users" file is also inefficient. I use a nested if statement to short-circuit, and sort by prevalence, but I do not have quite as many cases as you. OK, so this means I cannot use a switch/ case block because fr have to know all the ldap groups a user is in itself? I try to nest my code a bit better like you have mentioned, Brian. Regards, Tobias Hachmer - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: optimize questions for unlang code
> Tobias Hachmer wrote: > Now I'm coming closer to my questions. > When a local user logon to a telnet device freeradius does all the ldap > membership queries. > When an AD user will logon to a telnet device freeradius also does all > the ldap membership queries. > > Q1: Can I abbreviate this process that when a local user wants access > to a telnet device the ldap queries will be skipped? > Q2: Is there a smarter way to reject a local user immediately when he > wants to logon to a non telnet device? > Q3: Is there a smarter way to reject an AD user immediately when he > wants to logon to a telnet device? You could use Auth-Type subsections, but with LDAP the control flow can be a bit confusing (the statements in the block outside those sections all run, and then the block gets run again from the top once an Auth-Type is selected, which happens inside of the ldap module.) Your best bet for this scenario is to look at the "as of 2.0" instructions in clients.conf, where you can select a virtual server to enter based on which clients are requesting, and construct a separate virtual server for telnet devices. > Q4: Are there any tweaking capabilities to my unlang code to make it > smarter or more hardened? > Q5: Can I abbreviate any code snippets like using a switch/case block > or use variables or anything I don't know? When using Ldap-Group as a check item, you have to be careful, because it is a special case. You are not really comparing the value after the '==' to a variable, rather each time an LDAP group query is launched looking for the value after the '=='. This is the way LDAP groups work -- you do not query a list of groups, you query them one-by-one. Note that using Ldap-Group in the "users" file is also inefficient. I use a nested if statement to short-circuit, and sort by prevalence, but I do not have quite as many cases as you. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
optimize questions for unlang code
Hello listmembers,
In my testing environment I set up a virtual freeradius 2.1.12 server,
which is configured to do ntlm_auth for authentication and ldap
authorization against Microsoft AD.
These are my ldap groups:
- cn=radius.users,ou=Groups,dc=test,dc=local (only users within this
group are allowed to authenticate against AD)
- cn=alu.rw,ou=Groups,dc=test,dc=local (read-write group for
alcatel-lucent devices)
- cn=alu.ro,ou=Groups,dc=test,dc=local (read-only group for
alcatel-lucent devices)
- cn=netscreen.rw,ou=Groups,dc=test,dc=local (read-write group for
juniper netscreen devices)
- cn=netscreen.ro,ou=Groups,dc=test,dc=local (read-only group for
juniper netscreen devices)
- cn=nsm.rw,ou=Groups,dc=test,dc=local (read-write group for
juniper nsm)
- cn=nsm.ro,ou=Groups,dc=test,dc=local (read-only group for
juniper nsm)
- cn=aruba.rw,ou=Groups,dc=test,dc=local (read-write group for
aruba devices)
- cn=aruba.ro,ou=Groups,dc=test,dc=local (read-only group for
aruba devices)
I wrote unlang code in the authorize section of virtual server
"default" (will post this later)
- if a AD user is member of the radius.user I set Auth-Type to
"ntlm_auth"
- if a AD user is member of a device group above freeradius will add
the appropriate return attributes to the access-accept packet.
- if a AD user ist member of a read-write and a read-only group at once
the user will be rejected because I assume this will be a configuration
mistake.
This is working so far very well but there is another advantage:
Here are several devices which only support telnet access (yes, I know
I have to get rid of them as soon as possible). In my point of view it
would be fatal to logon to those devices with the active directory
account.
What I have done for now to authenticate non AD users only for these
devices:
- define these users in users file
- create a huntgroup telnet with all the NAS-IP-Addresses of these
devices
- create unlang code to set Auth-Type to PAP if a radius request is
received with one NAS-IP-Address defined in the huntgroup
unlang code below "preprocess" (authorize section of virtual server
"default):
if(Huntgroup-Name == xos) {
update control {
Auth-Type = pap
}
}
unlang code below "ldap" (authorize section of virtual server
"default):
# reject users which are member of a read-only and a read-write
group
if(Ldap-Group == "cn=alu.rw,ou=Groups,dc=test,dc=local" &&
Ldap-Group == "cn=alu.ro,ou=Groups,dc=test,dc=local") {
reject
}
elsif(Ldap-Group ==
"cn=netscreen.rw,ou=Groups,dc=test,dc=local" && Ldap-Group ==
"cn=netscreen.ro,ou=Groups,dc=test,dc=local") {
reject
}
elsif(Ldap-Group == "cn=nsm.rw,ou=Groups,dc=test,dc=local" &&
Ldap-Group == "cn=nsm.ro,ou=Groups,dc=test,dc=local") {
reject
}
elsif(Ldap-Group == "cn=aruba.rw,ou=Groups,dc=test,dc=local" &&
Ldap-Group == "cn=aruba.ro,ou=Groups,dc=test,dc=local") {
reject
}
# Allow only members of AD-Group
"cn=radius.users,ou=Groups,dc=test,dc=local" to authenticate against AD!
if(Ldap-Group == "cn=radius.users,ou=Groups,dc=test,dc=local")
{
update control {
Auth-Type = ntlm_auth
}
#
# Return-Attribute Section
#
# Return appropriate return attributes to members of
"cn=alu.rw,ou=Groups,dc=test,dc=local"
if(Ldap-Group ==
"cn=alu.rw,ou=Groups,dc=test,dc=local") {
update reply {
Alcatel-Access-Priv = Alcatel-Read-Priv
Alcatel-Access-Priv +=
Alcatel-Write-Priv
Alcatel-Access-Priv +=
Alcatel-Admin-Priv
Alcatel-Acce-Priv-F-W1 := 0x
Alcatel-Acce-Priv-F-W2 := 0x
Alcatel-Asa-Access := All
Service-Type := 6
}
}
# Return appropriate return attributes to members of
"cn=alu.ro,ou=Groups,dc=test,dc=local"
if(Ldap-Group == "cn=alu.ro,ou=Groups,dc=test,dc=local"
&& !Ldap-Group == "cn=alu.rw,ou=Groups,dc=test,dc=local") {
update reply {
Alcatel-Access-Priv :=
Alcatel-Read-Priv
Alcatel-Acce-Priv-F-R1 := 0x
Alcatel-Acce-Priv-F-R2 := 0x
Alcatel-Acce-Priv-F-W1 := 0x000A
Alcatel-Acce-Priv-F-W2 := 0x
Alcatel-Asa-Access := all
}
}
# Return appropriate return a
