One question relating to this is about the /etc/raddb/users file- It doesn't
seem to work as it's documented, If I have a group set to be rejected based
on its membership like this:
DEFAULT Group=disabled, Auth-Type:=Reject
radius doesn't even check for group membership. The only way it seems
Cool, thanks for pointing that out. My brain filtered out the '==', been
staring at this screen too long.
--
View this message in context:
http://freeradius.1045715.n5.nabble.com/Radius-authentication-against-LDAP-question-tp5713463p5713505.html
Sent from the FreeRadius - User mailing list
Nick- I have found that we can use any attribute for the access, but I'm
trying to expand our use of radius for another type of user login. In this
case I've created an LDAP group for the new user role and have created a new
radius virtual server to service the specific authentication and
The FAQ gives a *very* basic and less than complete example of using groups.
I found an old maillist entry that might be of help here. -
http://lists.freeradius.org/pipermail/freeradius-users/2007-June/019764.html
I'm trying to do something similar and I'm having trouble getting radius to
be
Playing with ldapsearch I see that the search string that radiusd -X is
reporting to use indeed does not work:
=ldapsearch filter (from radiusd -X)
performing search in cn=accounts,dc=abc,dc=xyz, with filter
((cn=newgroup)((objectclass=posixGroup)(memberUid=newuser)))
=
Returns no
I have a client system that seems to be ignoring changes in the pam_radius
config file, /etc/raddb/server. I initially configured the system with a
simple shared secret and had it pointed to a test server and now when I
change the file /etc/raddb/server the client still talks to the test server
Thanks, Alan. I definitely suspected both of the things you suggest, but I
initially installed this system and configured it, so I'm really confused as
to how this alternate configuration came to be. I found the rogue
configuration in the file /etc/pam_radius.conf . Unless I did that one
evening
I'm sure this won't surprise anyone, but the problem had nothing to do with
radius. I had only entered the radius module in the pam config for ssh, but
I had a kerberos config in the system auth pam config. When I enabled debug
for the radius module I saw the kerberos realm info being passed in
I am trying to get pam radius module to work but the module does not seem to
be encrypting properly. When I test using radtest authentication works, but
when attempting a pam authentication the password shows as garbage. I have
verified that the shared secret I'm using is the same for both
This is the output from the compile. Are the messages here anything to be
concerned with?
[root@csp pam_radius-1.3.17]# make
cc -Wall -fPIC -c pam_radius_auth.c -o pam_radius_auth.o
pam_radius_auth.c: In function ‘talk_radius’:
pam_radius_auth.c:886: warning: pointer targets in passing argument
I didn't think so, just making sure. I'll test more and post the output.
--
View this message in context:
http://freeradius.1045715.n5.nabble.com/compiling-pam-radius-module-tp4727149p4727533.html
Sent from the FreeRadius - User mailing list archive at Nabble.com.
-
List
Using radtest against radius in debug mode it works (output below.) One thing
to note is that this radius server is proxying authentication to a WiKID
server for 2 factor authentication. The password you see here is the one
generated by the software token.
=RADTEST
The NAS is a Linksys/Cisco SFE2000 switch. There is very little flexibility
in how to configure the switch and the documents do not detail how to
configure it for 802.1x or mac bypass, other than to say it can do it.
The client is a windows system being plugged into a port on the switch.
I will
I guess I was too quick to call it, and it looks like the problem is still on
the NAS. You will see that the client first gets access using the MAC
address as the CSID, but at some point, the client or NAS decieded to
re-auth but this time using the IP address that the client had acquired.
It's
I don't know why it wasn't working when I posted that last one, I had a
message that the port was not authenticated on the client, but the log I
posted clearly shows that it matched on the username of the switch since
there is an ldap user called admin and the switch admin user is also admin.
I've been looking at this for a day now and it seems like I'm close, but
something is not right. I have a freeradius server with an openldap backend
for MAC auth bypass. This system is just for test, but it is an essential
first step in my project.
I'm using freeradius2-2.1.7-7.el5,
I haven't yet done a test using strace but wanted to add what I did find when
I got started this morning. If I attempt to authenticate with the user
test1, password `qwer` (the correct password,) I get this response:
Wed Jun 15 08:40:19 2011 : Auth: rlm_krb5: [test1@CSP-BACK] krb5_rd_req()
d'oh! it was SElinux. I had disabled it temporarily, but didn't set it as
disabled in /etc/selinux/config so it was blocking the authentication.
Phil Mayers wrote:
On 06/14/2011 09:44 PM, Jimmy wrote:
I have Kerberos 1.6 configured to use OpenLDAP 2.3.43 as a back end. I
am trying to
18 matches
Mail list logo