Retrieve an user attribute from AD for vlan assignment in PEAP auth
Hi everyone, I am configuring a freeradius server with authentication PEAP/Mschap with an Active Directory. The authentication works :) There is my question: I have on my AD an attribute for each user such as "vlanId = 12" and I would like to get this value to assign the user authenticated on this VLAN. Any idea ? Thanks, Frad -- View this message in context: http://www.nabble.com/Retrieve-an-user-attribute-from-AD-for-vlan-assignment-in-PEAP-auth-tp22720035p22720035.html Sent from the FreeRadius - User mailing list archive at Nabble.com. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAp/TSL authorization problem
Are you trying to use TLS or PEAP? I'm not an expert but there are
some PEAP definitions in your config file that I think need to be changed
if you are attempting TLS. The most obvious is the default_eap_type
which should be tls.
default_eap_type = tls
Also, if you are attempting tls you don't need the user password in the
users file. I don't know if this will cause an error with TLS, but it's
not necessary to have.
If you are attempting PEAP, I don't see anything obvious in the config
file that is incorrect. You might look other places such as ensuring you
are using the XP Wireless Zero Configuration for accessing the wireless
network, and also recheck your certificate creation. I found
http://www.austux.net/resources/network/eaptls.html to be the most
helpful regarding certificate creation.
Jon
Sergey Guriev wrote:
Hello!
Im' using freeradius 1.02 (under linux), Cisco AiroNet 1230B and PC-station
under Win-XP. And I have some problem with authorization.
Here parts of my configs:
users:
-
ttt Password == ""
-
radiusd.conf:
-
authenticate {
#
# PAP authentication, when a back-end database listed
# in the 'authorize' section supplies a password. The
# password can be clear-text, or encrypted.
# Auth-Type PAP {
# pap
# }
#
# Most people want CHAP authentication
# A back-end database listed in the 'authorize' section
# MUST supply a CLEAR TEXT password. Encrypted passwords
# won't work.
# Auth-Type CHAP {
# chap
# }
#
# MSCHAP authentication.
Auth-Type MS-CHAP {
mschap
}
#
# If you have a Cisco SIP server authenticating against
# FreeRADIUS, uncomment the following line, and the 'digest'
# line in the 'authorize' section.
# digest
#
# Pluggable Authentication Modules.
# pam
#
# See 'man getpwent' for information on how the 'unix'
# module checks the users password. Note that packets
# containing CHAP-Password attributes CANNOT be authenticated
# against /etc/passwd! See the FAQ for details.
#
# unix
# Uncomment it if you want to use ldap for authentication
#
# Note that this means "check plain-text password against
# the ldap database", which means that EAP won't work,
# as it does not supply a plain-text password.
# Auth-Type LDAP {
# ldap
# }
#
# Allow EAP authentication.
eap
}
-
eap.conf:
-
eap {
default_eap_type = peap
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = yes
md5 {
}
leap {
}
gtc {
auth_type = PAP
}
## EAP-TLS
tls {
private_key_password = maddie
private_key_file = ${raddbdir}/certs/cert-srv.pem
certificate_file = ${raddbdir}/certs/cert.pem
check_cert_cn = no
CA_file = ${raddbdir}/certs/cacert.pem
dh_file = ${raddbdir}/certs/dh
random_file = /dev/urandom
rsa_key_exchange = no
dh_key_exchange = yes
# fragment_size = 1024
# include_length = yes
# check_crl = yes
# check_cert_cn = %{User-Name}
}
peap {
default_eap_type = mschapv2
}
mschapv2 {
}
}
-
Cisco:
--
Current configuration : 3127 bytes
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname ap
!
aaa new-model
!
!
aaa group server radius wifi
server 80.243.64.177 auth-port 1812 acct-port 1813
!
aaa group server radius wlccp_rad_infra
!
aaa group server radius wlccp_rad_eap
server 80.243.64.177 auth-port 1812 acct-port 1813
!
aaa group server radius wlccp_rad_leap
!
aaa group server radius wlccp_rad_mac
!
aaa group server radius wlccp_rad_any
!
aaa group server radius wlccp_rad_acct
!
aaa group server radius rad_eap
server 80.243.64.177 auth-port 1812 acct-port 1813
!
aaa group server radius rad_mac
!
aaa group server radius rad_acct
!
aaa group server radius rad_admin
!
aaa group server tacacs+ tac_admin
!
aaa group server radius rad_pmip
!
aaa group server radius dummy
!
aaa group server radius eap_methods
server 80.243.64.177 auth-port 1812 acct-port 1813
!
aaa authentication login wlccp_infra group wlccp_rad_infra
aaa authentication log
Re: TLS problem
A good resource is www.austux.net/resources/network/eaptls.html Also, make sure you are using "windows zero configuration" on the WinXP client. Jon [EMAIL PROTECTED] wrote: Hello, I'm tying to make an authentication using freeradius-1.0.1-1 on Fedora Core 3, Cisco Catalyst 2950 as authenticator and WinXP (SP2) as a client. I didn't manage to make it work and I found a document describing that I should make a TLS authentication first, then go to MS-CHAP v2, but it didn't work too. I found that the TLS connection doesn't establish completely but I can't find the problem. Can you tell me the reason it doesn't work or url to more descriptive document? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
TLS Certificate Challenge
FreeBSD V5.3 FreeRadius V1.0.2 Windows XP Home Dlink 2100 Access Point Dlink G132 USB Wireless Adapter self-signed server certificates using openssl v0.9.7e I'm using EAP/TLS successfully, however I'd like to have the user challenged to enter a password prior to being given access to the local network. Currently, the TLS certificates work without any user interaction. I thought this is what the "Challenge Password" was for when the certificate is created by openssl, but my laptop connects without requiring any challenge. When I imported the certificate I checked the box that required strict security and said that I'd be prompted every time the certificate was used. Does a challenge get initiated by XP, the certificate, or the wireless adapter? Looking for any help you can provide on this issue. Thanks, Jon - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: verify server certificate XP supplicant ?
Are you sure you used the "xpextensions" file when you built your server and client certificates? I had the same problem you describe until I added the xpextension (OID) stuff to the certificates. Try using the following resource, cut and pasting the commands as they appear within the document. I used this successfully for EAP/PEAP and EAP/TLS. Then make sure that your wireless adapter is configured to use TLS. Under Microsoft it's called "Smart Card or Certificate" within the the adapters properties dialog box. If your adapter came with its own configuration software there'll be a place to specify EAP/TLS. If you don't see such an option, your adapter is not 802.1x compliant. A great resource for EAP/TLS is austux.net/resources/network/eaptls.html Jon Riccardo Veraldi wrote: Hello, I am using EAP-TLS. Windows XP, Cisco 1200 AP, freeradius. Everything is working fine unless I enable the "verify server certificate" checkbox on XP. In this case I am not authenticated anymore by the radius server. I Cannot understand why. I have the CA certificate installed I cannot understand why it does not work. any hints ? thank you very much Rick - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: TLS Alert read:fatal:bad certificate
I resolved this issue. The problem was that I had not included the xpextensions when making the certificate. I got errors when initially trying to use CA.all and instead of investigating the errors further I decided to build a CA root and server cert manually, which did not include the xpextensions. My configuration is working so well now that I've stop using the -X option to watch the output. As usual however, my success has resulted in additional questions that I'd appreciate some help with. 1) What is an "OID"? Nice buzz word that I see referenced in numerous web pages but no definition. What is the purpose of the data in the xpextensions file? Do all CA's use it when signing certificates, or is this specific to freeradius? 2) I notice now that the certificate validation is working that I no longer am prompted to enter my username and password. Even after rebooting the WinXP computer, the connection to freeradius occurs automatically. I suppose this might be convenient in some circles but it's also a security risk in that if someone were to borrow my computer they would not be challenged before getting access to the network. Does anyone know where WinXP stores this info and if it can be configured to always prompt for user/pass? Thanks, Jon > >FreeBSD V5.3 >FreeRadius V1.0.2 >Windows XP Supplicant >Dlink 2100 Access Point >Dlink G132 USB Wireless Adapter >self-signed server certificates using openssl v0.9.7e > >The radiusd -X command shows no errors on startup. > >I'm having problems authenticating when using the "validate server certificate" >option in the WinXP PEAP configuration menu. If I don't validate the server >certificate I can connect to the radius server just fine. Someone else ran >into a similar problem (freeradius-users/2004-September/036349.html) claiming >the problem was "usage attributes accompanying the cert". I don't know what >this means. I created my certs according to directions from >austux.net/resources/network/eaptls.html > >The entire log is include below, but the relevant part seems to be the >following section. I'm assuming "validating" the certificate is a good >thing and an option I want to include in my WinXP configuration. My root >CA installed fine on the WinXP machine. Can anyone give me some guidance >on this issue? > > > rlm_eap_peap: EAPTLS_OK > rlm_eap_peap: Session established. Decoding tunneled attributes. > rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal access_denied >TLS Alert read:fatal:access denied >rlm_eap_peap: No data inside of the tunnel. > rlm_eap: Handler failed in EAP/peap > rlm_eap: Failed in EAP select > modcall[authenticate]: module "eap" returns invalid for request 53 >modcall: group authenticate returns invalid for request 53 >auth: Failed to validate the user. > > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
TLS Alert read:fatal:bad certificate
FreeBSD V5.3 FreeRadius V1.0.2 Windows XP Supplicant Dlink 2100 Access Point Dlink G132 USB Wireless Adapter self-signed server certificates using openssl v0.9.7e The radiusd -X command shows no errors on startup. I'm having problems authenticating when using the "validate server certificate" option in the WinXP PEAP configuration menu. If I don't validate the server certificate I can connect to the radius server just fine. Someone else ran into a similar problem (freeradius-users/2004-September/036349.html) claiming the problem was "usage attributes accompanying the cert". I don't know what this means. I created my certs according to directions from austux.net/resources/network/eaptls.html The entire log is include below, but the relevant part seems to be the following section. I'm assuming "validating" the certificate is a good thing and an option I want to include in my WinXP configuration. My root CA installed fine on the WinXP machine. Can anyone give me some guidance on this issue? rlm_eap_peap: EAPTLS_OK rlm_eap_peap: Session established. Decoding tunneled attributes. rlm_eap_tls: <<< TLS 1.0 Alert [length 0002], fatal access_denied TLS Alert read:fatal:access denied rlm_eap_peap: No data inside of the tunnel. rlm_eap: Handler failed in EAP/peap rlm_eap: Failed in EAP select modcall[authenticate]: module "eap" returns invalid for request 53 modcall: group authenticate returns invalid for request 53 auth: Failed to validate the user. COMPLETE LOG -- rad_recv: Access-Request packet from host 192.168.1.9:1044, id=0, length=195 Message-Authenticator = 0x4f9ccbaf3ab3be2586f9b6f5094a77b1 Service-Type = Framed-User User-Name = "jon" Framed-MTU = 1488 Called-Station-Id = "00-11-95-BF-B6-F9:radius1" Calling-Station-Id = "00-11-95-94-4F-CB" NAS-Identifier = "D-Link Corp. Access Point" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x0208016a6f6e NAS-IP-Address = 192.168.1.9 NAS-Port = 1 NAS-Port-Id = "STA port # 1" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 49 modcall[authorize]: module "preprocess" returns ok for request 49 modcall[authorize]: module "mschap" returns noop for request 49 rlm_realm: No '@' in User-Name = "jon", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 49 rlm_eap: EAP packet type response id 0 length 8 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 49 users: Matched entry jon at line 80 modcall[authorize]: module "files" returns ok for request 49 modcall: group authorize returns updated for request 49 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 49 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module "eap" returns handled for request 49 modcall: group authenticate returns handled for request 49 Sending Access-Challenge of id 0 to 192.168.1.9:1044 EAP-Message = 0x010100061920 Message-Authenticator = 0x State = 0x109fea2d826cbca009c3b29faa07d32c Finished request 49 Going to the next request --- Walking the entire request list --- Waking up in 6 seconds... rad_recv: Access-Request packet from host 192.168.1.9:1044, id=1, length=285 Message-Authenticator = 0xb476fe4ef81aa1687fc3be4696873ea2 Service-Type = Framed-User User-Name = "jon" Framed-MTU = 1488 State = 0x109fea2d826cbca009c3b29faa07d32c Called-Station-Id = "00-11-95-BF-B6-F9:radius1" Calling-Station-Id = "00-11-95-94-4F-CB" NAS-Identifier = "D-Link Corp. Access Point" NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x02010050198000461603010041013d03014260aa5d192deeca7552fd6ecd6ab3baa64d8c6b25c45e979cfcdf2fdac8c1b51600040005000a000900640062000300060013001200630100 NAS-IP-Address = 192.168.1.9 NAS-Port = 1 NAS-Port-Id = "STA port # 1" Processing the authorize section of radiusd.conf modcall: entering group authorize for request 50 modcall[authorize]: module "preprocess" returns ok for request 50 modcall[authorize]: module "mschap" returns noop for request 50 rlm_realm: No '@' in User-Name = "jon", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 50 rlm_eap: EAP packet type response id 1 length 80 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request
Re: EAP-TLS Certificate Failure with CMC Emulation Engine
Interesting. I've getting the same error on WinXP SP2 when I use the "validate server certificate" option in the PEAP configuration window. In fact, I was just about the send my log info to the list when I saw your mail. On your winxp client you might want to double-check if you have "validate server certificate" checked or not. If you do, can you send me the commands you used to create your certificates so I can try to get mine to work correctly? Jon > Background: > I am utilizing CMCs Emulation Engine to perform multi-client testing on a > wireless access point, which is configured for WPA 802.1x. I am running > EAP-TLS on FreeRADIUS 1.0.0-5 and OpenSSL 0.9.7d-25 on SuSE Linux > Professional 9.2. Before testing the access point with the Emulation > Engine I verified the FreeRADIUS configuration with Windows XP SP2 clients, > which allowed me to successfully associate, authenticate and transfer data > through the access point. > > Problem: > FreeRADIUS reports fatal bad_certificate when I try to associate and > authenticate the Emulation Engine with the access point. However, this is > the same client certificate I successfully used on the Windows clients. > > My contact at CMC built FreeRADIUS on a Redhat platform and tried to > troubleshoot the problem. Initially, he was unable to associate and > authenticate via the access point when running the Emulation Engine. He > eventually rebuilt his installation with the following configurations: > > OpenSSL: --no-shared > FreeRADIUS: --with-openssl-includes=/usr/local/ssl/include > --with-openssl-libraries=/usr/local/ssl/lib > --disable-shared > > After he rebuilt his installation he was able to successfully use my > certificates with the Emulation Engine. > > Questions: > What did his rebuild configurations change? > Can anyone provide insight into my FreeRADIUS errors captured below? > > - Thanks, Adam Gibson > > rad_recv: Access-Request packet from host xxx.xxx.xxx.xxx:5501, id=23, > length=202 > Message-Authenticator = 0xd9e136bede727a18ffebbe5029428d2a > Service-Type = Framed-User > User-Name = "laptop" > Framed-MTU = 1488 > State = 0xb9a81d87e3edf4ae5692cb71c2d3f34d > Called-Station-Id = ":xx--xxx-xx" > Calling-Station-Id = "" > NAS-Identifier = "" > NAS-Port-Type = Wireless-802.11 > Connect-Info = "CONNECT 54Mbps 802.11g" > EAP-Message = 0x020200060d00 > NAS-IP-Address = xxx.xxx.xxx.xxx > NAS-Port = 2 > NAS-Port-Id = "STA port # 2" > Processing the authorize section of radiusd.conf > modcall: entering group authorize for request 10 > modcall[authorize]: module "preprocess" returns ok for request 10 > modcall[authorize]: module "chap" returns noop for request 10 > modcall[authorize]: module "mschap" returns noop for request 10 > rlm_realm: No '@' in User-Name = "laptop", looking up realm NULL > rlm_realm: No such realm "NULL" > modcall[authorize]: module "suffix" returns noop for request 10 > rlm_eap: EAP packet type response id 2 length 6 > rlm_eap: No EAP Start, assuming it's an on-going EAP conversation > modcall[authorize]: module "eap" returns updated for request 10 > users: Matched laptop at 97 > modcall[authorize]: module "files" returns ok for request 10 > modcall: group authorize returns updated for request 10 > rad_check_password: Found Auth-Type EAP > auth: type "EAP" > Processing the authenticate section of radiusd.conf > modcall: entering group authenticate for request 10 > rlm_eap: Request found, released from the list > rlm_eap: EAP/tls > rlm_eap: processing type tls > rlm_eap_tls: Authenticate > rlm_eap_tls: processing TLS > rlm_eap_tls: Received EAP-TLS ACK message > rlm_eap_tls: ack handshake fragment handler > eaptls_verify returned 1 > eaptls_process returned 13 > modcall[authenticate]: module "eap" returns handled for request 10 > modcall: group authenticate returns handled for request 10 > Sending Access-Challenge of id 23 to xxx.xxx.xxx.xxx:5501 > EAP-Message = > 0x010303200d800716273025060355040a131e4c657669746f6e20566f69636520616e6 >420446174612044697669736f6e31133011060355040b130a416374697665204c61623114301 >20603550403130b4164616d20476962736f6e312b302906092a864886f70d010901161c61676 >962736f6e406c657669746f6e766f696365646174612e636f6d305c300d06092a864886f70d0 >101010500034b003048024100b9eb33f79f3aff24f1613023530ee0b512c4aec11c11840087e >9798f9da02446ff83854cf201fab7e2486a12f1e7fd406b1c34e7c38c29497d62765fae0ff48 >f0203010001a382011630820112301d0603551d0e041604143143 EAP-Message = > 0x009a0e958f0e4adccbc9e9e757ea7eb7d7173081e20603551d230481da3081d7801431430 >09a0e958f0e4adccbc9e9e757ea7eb7d717a181bba481b83081b5310b3009060355040613025 >553311330110603550408130a57617368696e67746f6e3110300e06035504071307426f74686 >56c6c31273025060355040a131e
Re: Compile problem of last CVS version on FreeBSD 4.x
Current CVS version also cannot be built on FreeBSD. Is where any way to fix the problem? Friday, November 19, 2004, 5:41:56 PM, [EMAIL PROTECTED] wrote: fuanr> Tried on two FreeBSD 4.x box fuanr> #gmake fuanr> gmake[1]: Entering directory `/root/src/radiusd' fuanr> Making all in libltdl... fuanr> gmake[2]: Entering directory `/root/src/radiusd/libltdl' fuanr> gmake[2]: *** No rule to make target `all'. Stop. fuanr> gmake[2]: Leaving directory `/root/src/radiusd/libltdl' fuanr> gmake[1]: *** [common] Error 1 fuanr> gmake[1]: Leaving directory `/root/src/radiusd' fuanr> gmake: *** [all] Error 2 fuanr> #uname -a fuanr> FreeBSD 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Mon Nov 10 15:58:43 MSK 2003 fuanr> configure:8639: checking if libtool supports shared libraries fuanr> configure:8641: result: yes fuanr> configure:8644: checking whether to build shared fuanr> libraries fuanr> configure:8702: result: yes fuanr> configure:8705: checking whether to build static fuanr> libraries fuanr> configure:8709: result: yes fuanr> configure:8801: creating libtool fuanr> configure:9348: checking for ld used by g++ fuanr> configure:9415: result: /usr/libexec/elf/ld fuanr> configure:9424: checking if the linker fuanr> (/usr/libexec/elf/ld) is GNU ld fuanr> configure:9439: result: yes fuanr> configure:9490: checking whether the g++ linker fuanr> (/usr/libexec/elf/ld) supports shared libraries fuanr> configure:10316: result: yes fuanr> I didn't found in config.log lines related to libltdl. fuanr> This version can be built successfully if copy libltdl dir from fuanr> release. fuanr> - fuanr> List info/subscribe/unsubscribe? See fuanr> http://www.freeradius.org/list/users.html -- Andrei Koulik. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Compile problem of last CVS version on FreeBSD 4.x
Tried on two FreeBSD 4.x box #gmake gmake[1]: Entering directory `/root/src/radiusd' Making all in libltdl... gmake[2]: Entering directory `/root/src/radiusd/libltdl' gmake[2]: *** No rule to make target `all'. Stop. gmake[2]: Leaving directory `/root/src/radiusd/libltdl' gmake[1]: *** [common] Error 1 gmake[1]: Leaving directory `/root/src/radiusd' gmake: *** [all] Error 2 #uname -a FreeBSD 4.9-RELEASE FreeBSD 4.9-RELEASE #0: Mon Nov 10 15:58:43 MSK 2003 configure:8639: checking if libtool supports shared libraries configure:8641: result: yes configure:8644: checking whether to build shared libraries configure:8702: result: yes configure:8705: checking whether to build static libraries configure:8709: result: yes configure:8801: creating libtool configure:9348: checking for ld used by g++ configure:9415: result: /usr/libexec/elf/ld configure:9424: checking if the linker (/usr/libexec/elf/ld) is GNU ld configure:9439: result: yes configure:9490: checking whether the g++ linker (/usr/libexec/elf/ld) supports shared libraries configure:10316: result: yes I didn't found in config.log lines related to libltdl. This version can be built successfully if copy libltdl dir from release. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
