I am investigating 2 factor authentication in which mostly they are radius server actually.
My problem is that most of my applications relying on LDAP auth only.
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn't figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
---
Jetasik (JET)
Manager, Transniaga(Thailand)
On 08/15/12 00:21 +0700, JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
Can you describe what kind of two factor authentication you are looking to support?
My problem is that most of my applications relying on LDAP auth only.
If you desire to support RADIUS authentication, with your authentication database stored within OpenLDAP, take a look at the FreeRADIUS ldap backend.
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn't figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
I have not used the radius module, so I can't answer this question.
Dan White wrote:
On 08/15/12�00:21�+0700, JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
Can you describe what kind of two factor authentication you are looking to support?
It is hardware(token) OTP, response only.
My problem is that most of my applications relying on LDAP auth only.
If you desire to support RADIUS authentication, with your authentication database stored within OpenLDAP, take a look at the FreeRADIUS ldap backend.
Nope. The 2FA authentication server is Radius server and almost of my applications right now is doing LDAP auth, cannot do Radius auth. I am looking for LDAP with Radius backend or maybe LDAP proxy(auth) to Radius backend...
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure
it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn't figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
I have not used the radius module, so I can't answer this question.
-- Dan White
-- JET JETASIK
JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
My problem is that most of my applications relying on LDAP auth only.
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn’t figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Read the radius.conf(5) manpage.
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
Yes, {RADIUS} followed by whatever your radius server thinks is a valid username.
If by 2-factor authentication you mean some kind of challenge/response method, that will not work. The module has no way to relay the challenge back to the LDAP client, and the LDAP Simple Bind request doesn't support challenge/response type authentication.
Howard Chu wrote:
JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
My problem is that most of my applications relying on LDAP auth only.
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure
it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn't figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Read the radius.conf(5) manpage.
Oh! It is just standard radius.conf format actually ?
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
Yes, {RADIUS} followed by whatever your radius server thinks is a valid username.
If by 2-factor authentication you mean some kind of challenge/response method, that will not work. The module has no way to relay the challenge back to the LDAP client, and the LDAP Simple Bind request doesn't support challenge/response type authentication.
Just like that? In my case it is response only, should be ok right? Thanks a lot Howard.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
--- JET JETASIK
Still got any luck yet. Nothing hit my radius server when doing simple auth to openldap. Any clue on how to check this.
Here is my /etc/radius.conf auth 192.168.0.10:1812 secret
-- JET JETASIK
Howard Chu wrote:
JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
My problem is that most of my applications relying on LDAP auth only.
I am trying to figure out on how to use openldap/contrib/slapd-modules/passwd/radius.c
I did compile and successfully loaded it but not sure how to configure
it.
This is what I put into slapd.conf to load the module:
moduleload pw-radius.so config="/etc/radius.conf"
Firstly I couldn't figure out what exactly is the format of /etc/radius.conf (Mandatory items: Radius server IP& Share Secret)
Read the radius.conf(5) manpage.
Oh! It is just standard radius.conf format actually ?
Secondly the format of userpassword scheme, {RADIUS}XXXXYYY@ZZZ ??
Yes, {RADIUS} followed by whatever your radius server thinks is a valid username.
If by 2-factor authentication you mean some kind of challenge/response method, that will not work. The module has no way to relay the challenge back to the LDAP client, and the LDAP Simple Bind request doesn't support challenge/response type authentication.
Just like that? In my case it is response only, should be ok right? Thanks a lot Howard.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
JET JETASIK
On Wed, 15 Aug 2012, JET JETASIK wrote:
Still got any luck yet. Nothing hit my radius server when doing simple auth to openldap. Any clue on how to check this.
Here is my /etc/radius.conf auth 192.168.0.10:1812 secret
There aren't that many moving parts...
* Maybe try explicitly configuring timeout and numtries (fields 4 and 5) ... my radius.conf has them, the man page implies defaults but who knows.
* Quick check might be to do a truss/strace/etc. on the open() family to see if anything .*radius.* is being read, perhaps not in the path you were expecting. (You should see this once per bind.)
* Turn up slapd debugging, make sure you're getting to the bind in the first place in terms of ACLs, etc.
* Attach a debugger, break on chk_radius. It's not that complex a function...
Aaron Richton wrote:
On Wed, 15 Aug 2012, JET JETASIK wrote:
Still got any luck yet. Nothing hit my radius server when doing simple auth to openldap. Any clue on how to check this.
Here is my /etc/radius.conf auth 192.168.0.10:1812 secret
There aren't that many moving parts...
- Maybe try explicitly configuring timeout and numtries (fields 4 and 5)
... my
radius.conf has them, the man page implies defaults but who knows.
Also tried with no luck.
- Quick check might be to do a truss/strace/etc. on the open() family to
see if
anything .*radius.* is being read, perhaps not in the path you were expecting. (You should see this once per bind.)
Frankly speaking I am not working as programmer/developer, I merely catch it up a bit.
From truss during simple bind, I can see it read the radius.conf and
sendto() my radius server, also got recvfrom() it, but nothing hit my radius server actually. Below is output of truss -p <slapd_pid>
exit(0x11) = 454 (0x1c6) accept(7,{ AF_INET 172.16.16.97:49479 },0x7ffffebfbc2c) = 9 (0x9) write(5,"0",1) = 1 (0x1) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) select(17,{4 6 7},0x0,0x0,0x0) = 1 (0x1) read(4,"0",1024) = 1 (0x1) setsockopt(0x9,0x6,0x1,0x7ffffebfbc28,0x4,0x0) = 0 (0x0) getpid() = 4200 (0x1068) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) sigprocmask(SIG_BLOCK,0x0,0x0) = 0 (0x0) open("/etc/hosts.allow",O_RDONLY,0666) = 18 (0x12) fstat(18,{ mode=-rw-r--r-- ,inode=1278751,size=3353,blksize=32768 }) = 0 (0x0) read(18,"#\n# hosts.allow access control "...,32768) = 3353 (0xd19) close(18) = 0 (0x0) sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) fcntl(9,F_GETFL,) = 6 (0x6) fcntl(9,F_SETFL,O_NONBLOCK|0x2) = 0 (0x0) write(5,"0",1) = 1 (0x1) read(4,"0",1024) = 1 (0x1) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) select(17,{4 6 7 9},0x0,0x0,0x0) = 1 (0x1) -- UNKNOWN SYSCALL 8769568 -- getpid() = 4200 (0x1068) sendto(3,"<167>Aug 16 10:37:04 slapd[4200]"...,99,0x0,NULL,0x0) = 3 (0x3) compat.creat(0x9,0x81846006f,0x8,0x0,0x50,0x0) = 99 (0x63) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) fchdir(0x7fffff3fcb50,0x18726,0x441050,0x0,0x0,0x502c6ae0) = 3 (0x3) fchflags(0x9,0x817c6056f,0x8,0x0,0x50,0x7fffff3fc93f) = 4 (0x4) exit(0x5) = 1 (0x1) exit(0x4) = 232 (0xe8) getpid() = 232 (0xe8) sendto(3,"<167>Aug 16 10:37:04 slapd[4200]"...,110,0x0,NULL,0x0) = 93 (0x5d) open("/dev/random",O_RDONLY,00) = 18 (0x12) read(18,"\M-I\M^^o^_\M^C*\M-2\\M-x\M-Q"...,124) = 124 (0x7c) close(18) = 0 (0x0) open("/etc/radius.conf",O_RDONLY,0666) = 18 (0x12) fstat(18,{ mode=-rw-r--r-- ,inode=1278806,size=28,blksize=32768 }) = 0 (0x0) read(18,"auth 10.10.10.9:1812 secret\n",32768) = 28 (0x1c) read(18,0x817c6a000,32768) = 0 (0x0) close(18) = 0 (0x0) socket(PF_INET,SOCK_DGRAM,17) = 18 (0x12) bind(18,{ AF_INET 0.0.0.0:0 },16) = 0 (0x0) sendto(18,"^A\M-y\08\M^T\M^V\M-K\M-~\a\M-*"...,56,0x0,{ AF_INET 10.10.10.9:1812 },0x10) = 56 (0x38) gettimeofday({1345088224.408943 },0x0) = 0 (0x0) select(19,{18},0x0,0x0,{3.000000 }) = 1 (0x1) recvfrom(18,"^C\M-y\0^T\M-FB\M-N\M-"\\M^_"...,4096,0x40,{ AF_INET 10.10.10.9:1812 },0x7fffff3fb62c) = 20 (0x14) close(18) = 0 (0x0) write(9,"0\f^B^A^Aa\a\n^A1^D\0^D\0",14) = 14 (0xe) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) getpid() = 4200 (0x1068) sendto(3,"<167>Aug 16 10:37:04 slapd[4200]"...,75,0x0,NULL,0x0) = 75 (0x4b) exit(0x11) = 454 (0x1c6) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) read(9,0x817c6056f,8) = 0 (0x0) select(17,{4 6 7},0x0,0x0,0x0) = 1 (0x1) read(4,"0",1024) = 1 (0x1) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) shutdown(9,SHUT_RDWR) = 0 (0x0) close(9) = 0 (0x0) clock_gettime(13,{1345088224.000000000 }) = 0 (0x0) getpid() = 4200 (0x1068) sendto(3,"<167>Aug 16 10:37:04 slapd[4200]"...,73,0x0,NULL,0x0) = 73 (0x49)
- Turn up slapd debugging, make sure you're getting to the bind in the
first
place in terms of ACLs, etc.
- Attach a debugger, break on chk_radius. It's not that complex a
function...
Here is slapd log. Aug 16 10:37:04 freebsd slapd[4200]: conn=1004 fd=9 ACCEPT from IP=172.16.16.97:49479 (IP=0.0.0.0:389) Aug 16 10:37:04 freebsd slapd[4200]: conn=1004 op=0 BIND dn="cn=xxx,ou=xxx,dc=xxx,dc=xx,dc=xx" method=128 Aug 16 10:37:04 freebsd slapd[4200]: conn=1004 op=0 RESULT tag=97 err=49 text= Aug 16 10:37:04 freebsd slapd[4200]: conn=1004 fd=9 closed (connection lost)
--- JET JETASIK
On Thu, 16 Aug 2012, JET JETASIK wrote:
From truss during simple bind, I can see it read the radius.conf and sendto() my radius server, also got recvfrom() it, but nothing hit my radius server actually. Below is output of truss -p <slapd_pid>
Honestly, that looks like it *is* working from the client perspective. If you're asserting that nothing hit your radius server, I'd take a few minutes with wireshark/tcpdump/snoop/etc. and see if that's true (run it on both sides). If the server-side captures show nothing then fix the network so the packet gets seen by the server. If the captures show 2-way conversation then fix your radius server so it logs/debugs the packet that the kernel's actually getting.
Also, it might be worth getting a copy of radtest or similar program and getting that working on the box running slapd. Ideally, said test program would be linked against the same libradius as slapd.
Aaron Richton wrote:
On Thu, 16 Aug 2012, JET JETASIK wrote:
From truss during simple bind, I can see it read the radius.conf and sendto() my radius server, also got recvfrom() it, but nothing hit my radius server actually. Below is output of truss -p <slapd_pid>
Honestly, that looks like it *is* working from the client perspective. If
you're
asserting that nothing hit your radius server, I'd take a few minutes with wireshark/tcpdump/snoop/etc. and see if that's true (run it on both
sides). If
the server-side captures show nothing then fix the network so the packet gets seen by the server. If the captures show 2-way conversation then fix your radius server so it logs/debugs the packet that the kernel's actually getting.
Also, it might be worth getting a copy of radtest or similar program and getting that working on the box running slapd. Ideally, said test program would be linked against the same libradius as slapd.
Sorry it's my careless, actually it hit my radius server but this kind of log will only be shown when turning on full-trace logging level. Same machine with radtest, to my radius server, the request is valid but not with openldap's radius module as it lacks an attribute as seen from the below log.
[2012/08/16|14:06:22.578125][02492][MINOR][ValidationTask::getNASLocationFro mPacket] > No NAS-IP or NAS-Identifier attribute found. [2012/08/16|14:06:22.578125][02492][MAJOR][ValidationTask::routePacket] > Rejecting RADIUS request due to missing NAS Location
I don't see there is option to define the NAS-IP or NAS-Identifier in /etc/radius.conf Furthermore I dig into openldap's radius.c, only RAD_USER_NAME and RAD_USER_PASSWORD(line 82, 86) attached into the request. Please advise how to put NAS-IP/NAS-Identifier into the request, maybe using rad_put_addr() ?
-- JET JETASIK
On Thu, 16 Aug 2012, JET JETASIK wrote:
[2012/08/16|14:06:22.578125][02492][MINOR][ValidationTask::getNASLocationFro mPacket] > No NAS-IP or NAS-Identifier attribute found. [2012/08/16|14:06:22.578125][02492][MAJOR][ValidationTask::routePacket] > Rejecting RADIUS request due to missing NAS Location
I don't see there is option to define the NAS-IP or NAS-Identifier in /etc/radius.conf Furthermore I dig into openldap's radius.c, only RAD_USER_NAME and RAD_USER_PASSWORD(line 82, 86) attached into the request. Please advise how to put NAS-IP/NAS-Identifier into the request, maybe using rad_put_addr() ?
I would think it would be easier to reconfigure your radius server to allow the queries in their existing form?
With that said, if you want to send additional attributes, a modification to radius.c is probably the right track. You'd probably be best inquiring to the Radius community about how to do this -- I certainly don't know their API off the top of my head and it's out of scope for openldap-technical.
Aaron Richton wrote:
On Thu, 16 Aug 2012, JET JETASIK wrote:
[2012/08/16|14:06:22.578125][02492][MINOR][ValidationTask::getNASLocat
ionFro mPacket] > No NAS-IP or NAS-Identifier attribute found. [2012/08/16|14:06:22.578125][02492][MAJOR][ValidationTask::routePacket ] > Rejecting RADIUS request due to missing NAS Location
I don't see there is option to define the NAS-IP or NAS-Identifier in /etc/radius.conf Furthermore I dig into openldap's radius.c, only RAD_USER_NAME and RAD_USER_PASSWORD(line 82, 86) attached into
the
request. Please advise how to put NAS-IP/NAS-Identifier into the request, maybe using rad_put_addr() ?
I would think it would be easier to reconfigure your radius server to
allow the
queries in their existing form?
With that said, if you want to send additional attributes, a modification
to
radius.c is probably the right track. You'd probably be best inquiring to
the
Radius community about how to do this -- I certainly don't know their API
off
the top of my head and it's out of scope for openldap-technical.
It took me some times to find out that if a radius-request, like this openldap-contrib's radius.c, does not include either a NAS-IP or a NAS-Identifier, it complies with old Radius RFC standard(RFC 2138), "SHOULD contain", but not the new one(RFC 2865) "MUST contain".
-- JET JETASIK
JET JETASIK wrote:
Aaron Richton wrote:
On Thu, 16 Aug 2012, JET JETASIK wrote:
[2012/08/16|14:06:22.578125][02492][MINOR][ValidationTask::getNASLocat
ionFro mPacket] > No NAS-IP or NAS-Identifier attribute found. [2012/08/16|14:06:22.578125][02492][MAJOR][ValidationTask::routePacket ] > Rejecting RADIUS request due to missing NAS Location
I don't see there is option to define the NAS-IP or NAS-Identifier in /etc/radius.conf Furthermore I dig into openldap's radius.c, only RAD_USER_NAME and RAD_USER_PASSWORD(line 82, 86) attached into
the
request. Please advise how to put NAS-IP/NAS-Identifier into the request, maybe using rad_put_addr() ?
I would think it would be easier to reconfigure your radius server to
allow the
queries in their existing form?
With that said, if you want to send additional attributes, a modification
to
radius.c is probably the right track. You'd probably be best inquiring to
the
Radius community about how to do this -- I certainly don't know their API
off
the top of my head and it's out of scope for openldap-technical.
It took me some times to find out that if a radius-request, like this openldap-contrib's radius.c, does not include either a NAS-IP or a NAS-Identifier, it complies with old Radius RFC standard(RFC 2138), "SHOULD contain", but not the new one(RFC 2865) "MUST contain".
Sounds like you should submit an ITS. With a patch fixing the issue, preferably.
Howard Chu wrote:
JET JETASIK wrote:
I am investigating 2 factor authentication in which mostly they are radius server actually.
My problem is that most of my applications relying on LDAP auth only.
If by 2-factor authentication you mean some kind of challenge/response method, that will not work. The module has no way to relay the challenge back to the LDAP client, and the LDAP Simple Bind request doesn't support challenge/response type authentication.
IIRC the RADIUS service of RSA SecurID accepted the personal token PIN and the OTP concantenated in a single RADIUS request. No need for extra challenge response PDUs in this case. But it feels like 2-factor authc for the user.
Ciao, Michael.
openldap-technical@openldap.org
-
Aaron Richton -
Dan White -
Howard Chu -
JET JETASIK -
Michael Ströder