Old school: FreeRADIUS and NIS
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I know it's throwback to the '90s, but my boss wants it done, so I need to do it. I /cannot/ find any documentation on setting up FreeRADIUS with NIS authentication. Does someone have some lying around somewhere? I've googled the Web as well as the Mail Archive and I got precisely two items out of a good 4 hours of searching. 1. I need to set DEFAULT Auth-Type = System 2. The only list post about NIS (from 2002) mentions using rlm_unix....and nothing else. I'm not new to linux, just FreeRADIUS. I'm know it seems silly to set this up using NIS, but we use it in house (for now) and my boss wants it done 'yesterday' and I don't have the time at the moment to migrate everything to LDAP. That's in the works, but he doesn't want to wait for the switch to LDAP before getting this working. Help! - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTGe2IAAoJEM/YzwEAv6e7ki0H/3l4UG/TBOeNaBPLSmmySgY3 RvnR7G33NzcPTJmwlOQXDnVhUbm0aRo9/ptfw+1ZQBbwxmrfl7j5HaXkoYhyQmxG ZL+uFdRZ26YzTxHq8pGVcvp+XVhHiQcTcKvNspeVEiM1QRgFAT2GBKFiv57etmoz ihKC4+gv699cs3By7474uTYAkWaPVUMeveFnuL81QPMLHE+Z4SDC+i5T2QRDaIz/ AfUWwzZsvJfeInn35Vsx7YLd1JUBoZHNk9l/gC7d7v/HQ7nPEEa2Uv05j7uJXXBW FE9O/Xjryndz4jovy3McR1ldOs+k5vRpxmO+YVebAb/PtMImBp7TVVLQkICsblc= =c6jI -----END PGP SIGNATURE-----
On Fri, Mar 07, 2014 at 11:02:19AM -0500, Mark Haney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know it's throwback to the '90s, but my boss wants it done, so I need to do it. I /cannot/ find any documentation on setting up FreeRADIUS with NIS authentication. Does someone have some lying around somewhere? I've googled the Web as well as the Mail Archive and I got precisely two items out of a good 4 hours of searching.
1. I need to set DEFAULT Auth-Type = System 2. The only list post about NIS (from 2002) mentions using rlm_unix....and nothing else.
I'm not new to linux, just FreeRADIUS. I'm know it seems silly to set this up using NIS, but we use it in house (for now) and my boss wants it done 'yesterday' and I don't have the time at the moment to migrate everything to LDAP. That's in the works, but he doesn't want to wait for the switch to LDAP before getting this working.
Help!
- -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64
Hi Mark, Can't you just use basic user auth to access NIS. I do not think it is anything special. Regards, Ken
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/07/14 11:09, ktm@rice.edu wrote:
Hi Mark,
Can't you just use basic user auth to access NIS. I do not think it is anything special.
Regards, Ken
Well, that's what I thought, but I can't seem to get it working. And all I'm doing now is testing the setup on the FreeRADIUS server, which is also the NIS server. It may be that I have the correct pieces, but not in the correct places. I'm still working out the configuration files and such. In the users file I've setup DEFAULT Auth-Type = System. According to what little documentation I can find, this /should/ 'just work' with NIS. I've left the clients.conf file as is for testing. I know I can setup a user in the users file with something like this: testing Cleartext-Password := "password" And that works just fine. Maybe I'm just not quite clear enough on the bits and pieces to work out the problem. I will be glad to post the debug output if needed, but it seems like it should be nothing more complicated that what I've got. I've not even come close to testing other devices authenticating yet, just trying it directly on localhost. Does that make sense? - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTGfReAAoJEM/YzwEAv6e7xM8IAIzNkxAxlbrS7I31xsePyoJd hMbCu8M5VqJt7ESgZI+LxxS+NZmn9YbVrtshOYhgBr28/O83XkvK7QFPNvlKgW1V xkwKBxwUIyxhKZ/PJTmR964CmONmstCYkFjetz4/+dQ2vhUCwOjmMaEb55+emfsN BfscJmCJZCUu0Bw9RLOZp10sgAo2Rkl8jx4vegwbt7bc1XJoQSWRD6JAaLlbCavi zJiurOo3hZVPH0ZUhvkasV7TfItyKuTRMvMRviS9xtQVkZHCGpOFK7SwNYfsQIjv WtCRFqo0Sa7tBh5MrQmPQ0TrlQZen8v2UdWTda1sHA4n9aJSIM63IYTumQU6OXs= =UCtX -----END PGP SIGNATURE-----
On 07/03/14 16:02, Mark Haney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I know it's throwback to the '90s, but my boss wants it done, so I need to do it. I /cannot/ find any documentation on setting up FreeRADIUS with NIS authentication. Does someone have some lying
Authentication of what? VPN, wireless 802.1x, etc? NIS basically gives you a Unix passwd entry, which is a crypt; thus, it's only compatible with PAP, or protocols that encapsulate PAP such as EAP-TTLS/PAP. See: http://deployingradius.com/documents/protocols/compatibility.html In principle, rlm_unix should work with NIS; it will set the Crypt-Password control item, which will be looked at by rlm_pap. It should be as simple as: authorize { ... unix pap ... } authenticate { Auth-Type PAP { pap } ... } Try this, post a debug of it not working if so.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
In principle, rlm_unix should work with NIS; it will set the Crypt-Password control item, which will be looked at by rlm_pap. It should be as simple as:
authorize { ... unix pap ... } authenticate { Auth-Type PAP { pap } ... }
Try this, post a debug of it not working if so.
Well, I've tried that and I still get a REJECT. I've attached the output, one is for the startup output from 'radiusd -X', the radius_debug_serveroutput.txt file is the output when I run radtest. The only thing I've changed in the config files is to add the DEFAULT Auth-Type = System at the top of the users file. In the authorize section of sites-enabled/default Unix was commented out, but I uncommented it. Everything else was as you list above. Now that I think about it, I don't even NEED FreeRADIUS to use NIS, since I'm running radiusd on the NIS master, the logins are all there in /etc/passwd anyway. Well, that simplifies things a bunch. But it still doesn't explain why I can't get any user to authenticate on that server. - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTGhD2AAoJEM/YzwEAv6e7I7QH/3qJRBEpt2TfTdJS1migV9fp 3fv6bQjXe0BdEifcHfbJzo3m/ftiKX9AK5F88fINUdvcbnJQzbCC0PqbVuHNoElz sW6ChKWg4brjUtiJQHxoQE+FKdF1ltvObAQ7NAueWuCsh9KLj/Yggjmq2tQ6PPjn aYNJG5L+mX9NpBv+ge7oRwFn9MG6APS5tqGsY/W69L9szAb6ItYbYzrA7tTX1y4Y jL8wE6h0Qb3ZUb2jhzNx+w3AxP9csc/lf6+27Kx9lsrKx6i0EwLYFaVHHEL7Kxms tpXAYKJ2p1r9XT+QodsVTBi97oDdFfROs/S3rQTIn8rV8Oh1p1fJopKBYeA70fg= =ff36 -----END PGP SIGNATURE-----
Mark Haney wrote:
Well, I've tried that and I still get a REJECT. I've attached the output, one is for the startup output from 'radiusd -X', the radius_debug_serveroutput.txt file is the output when I run radtest. The only thing I've changed in the config files is to add the DEFAULT Auth-Type = System at the top of the users file.
Which I don't recommend you do. Anyawyas, debug mode shows: ++[unix] returns notfound Which is pretty definitive. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/07/14 16:00, Alan DeKok wrote:
The only thing I've changed in the config files is to add the DEFAULT Auth-Type = System at the top of the users file.
Which I don't recommend you do.
Anyawyas, debug mode shows:
++[unix] returns notfound
Which is pretty definitive.
Okay, what would recommend then? And the ++[unix] returns notfound is definitive of /what/? Since I'm setting up FreeRADIUS on my NIS master, I don't really need NIS integration, the user accounts are all in /etc/passwd (and /etc/shadow) so all I need is radiusd to check for local accounts and authenticate against them. This /should/ simplify things, but apparently I'm missing something, and something probably relatively simple. Question is, what? - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHcZEAAoJEM/YzwEAv6e7VfIH+gLyCl0i8wJg8yrNRh93PUKG tuKKRyelWUur6p1Hem/G3LtEBkczbfPw1Mk1mD0McWmrH58lMoFccnFp3KF//QF7 NNBBrbbtkFLq0gdEUr7vr7ICXDqRKnrSSSh+zjOFZ5DwG4pSjhexqwgRZNw34prg ddG6qsnVwktztIBuiXI05iWL1yqoTVveiXJCRcoOFMc1cKABt4tYR0y2/7QGmjT2 DvfvhD3K+pDtO1HLwPOKay9D47AHSsRyvO64d1zfSVokt/7/FLbUuHtoZ9lXK5uH BjteP//mlE017d848wHF5PzmYXIPQhT3ANQ274TB/Q9wPalhx/7KMd+WN6CvHeA= =QgVT -----END PGP SIGNATURE-----
Mark Haney wrote:
++[unix] returns notfound
Which is pretty definitive.
Okay, what would recommend then? And the ++[unix] returns notfound is definitive of /what/?
Uh.... the module looks users up in /etc/passwd. What could "notfound" possibly mean?
Since I'm setting up FreeRADIUS on my NIS master, I don't really need NIS integration, the user accounts are all in /etc/passwd (and /etc/shadow) so all I need is radiusd to check for local accounts and authenticate against them. This /should/ simplify things, but apparently I'm missing something, and something probably relatively simple. Question is, what?
The user isn't in /etc/passwd. Alan DeKok.
On 10/03/14 14:03, Mark Haney wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/07/14 16:00, Alan DeKok wrote:
The only thing I've changed in the config files is to add the DEFAULT Auth-Type = System at the top of the users file.
Which I don't recommend you do.
Anyawyas, debug mode shows:
++[unix] returns notfound
Which is pretty definitive.
Okay, what would recommend then? And the ++[unix] returns notfound is definitive of /what/?
rlm_unix has a flow like this: r = getpwnam(username) if not r: return NOTFOUND if not r.passwd or len(r.passwd) < 10: s = getspnam(username) if not s: return NOTFOUND passwd = s.passwd else: passwd = r.passwd So, either FreeRADIUS is getting no reply to getpwnam() or it's getting an empty or "x" value for the password hash at that stage, *then* calling getspnam() and getting no value. My NIS is rusty, but IIRC calling the getspnam() routines under NIS requires you being root? Most likely this is the problem. PAM has a suid-root helper for this; FreeRADIUS doesn't. So one possible alternative would be to use rlm_pam, and let PAM do the work of getting at the shadow data.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/14 10:33, Phil Mayers wrote:
rlm_unix has a flow like this:
r = getpwnam(username) if not r: return NOTFOUND if not r.passwd or len(r.passwd) < 10: s = getspnam(username) if not s: return NOTFOUND passwd = s.passwd else: passwd = r.passwd
So, either FreeRADIUS is getting no reply to getpwnam() or it's getting an empty or "x" value for the password hash at that stage, *then* calling getspnam() and getting no value.
My NIS is rusty, but IIRC calling the getspnam() routines under NIS requires you being root? Most likely this is the problem.
Le me re-iterate. Since I've installed FreeRADIUS on my NIS master, I no longer care so much about dealing with NIS. At this stage, it's simply a matter of getting FR and rlm_unix to see and access my local user/pwd sitting in /etc/passwd and /etc/shadow. Surely, setting up Fr for that is not /that/ complicated. So, forget about NIS. That is not a problem. So, now that I have that out of the way, it seems rlm_unix isn't able to read /etc/shadow. I'm assuming the getspnam(username) call is trying to read /etc/shadow? If so, how is the best way to fix this? I read somewhere that rlm_unix didn't need to copy the password files into a temp file with radwtmp unless there was a specific reason for it. What exactly is that all about? - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHeb2AAoJEM/YzwEAv6e7EtsH/1DSyXULTwGN2Y4x/lvq/5cj OYj585upGm0gZlNTEBjDYF1eJQw+S26bIhbogiaaWElBhnNE43K0iXnlJMxC3rwJ ZRdoT5dQHufyOAFpDrg0GvR4BsnlSUlRzckBDGdFSsEtHHUtH0UU/ajuKo8JgXxZ 4smQ1dl9dFY9A9xe7AI7MGMI76QAqTIuTREmEwfPVKl9HSsBHAFr64hzxsUc8TcE 5GEizfXQv3XvTLsYuDCPRF2SxZr5ZpLi3Yuu/GLlC6Vl88qpNHgbPVf5rKw1NVMl OhYFHSnz+pzgyAKJBg3Np5xoV1cvDYf0wQ3Kv0i1UwP3SF4r9RvdAPNjyyzjZJc= =mS2E -----END PGP SIGNATURE-----
On 10/03/14 16:23, Mark Haney wrote:
So, now that I have that out of the way, it seems rlm_unix isn't able to read /etc/shadow. I'm assuming the getspnam(username) call is trying to read /etc/shadow? If so, how is the best way to fix this?
Set the permissions on /etc/shadow. Alternatively, to repeat myself, rlm_pam might work, as PAM has an setuid-root helper to read /etc/shadow.
I read somewhere that rlm_unix didn't need to copy the password files into a temp file with radwtmp unless there was a specific reason for it. What exactly is that all about?
No idea, sounds like gibberish to me.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/14 12:40, Phil Mayers wrote:
On 10/03/14 16:23, Mark Haney wrote:
So, now that I have that out of the way, it seems rlm_unix isn't able to read /etc/shadow. I'm assuming the getspnam(username) call is trying to read /etc/shadow? If so, how is the best way to fix this?
Set the permissions on /etc/shadow.
Alternatively, to repeat myself, rlm_pam might work, as PAM has an setuid-root helper to read /etc/shadow.
Good lord, this is just getting kinda silly. So, I suppose I can 'chgrp radiusd /etc/shadow' and set read permissions with 'chmod +r /etc/shadow' and have it work, but everything I see says not to do that. I found a post saying to use the passwd module, but the comments in it say to use either PAM or rlm_unix. I quick check of the comments in rlm_unix say that as of v1.1.0 unix can no longer read of cache /etc/shadow and to use the passwd module. That's some crackerjack documentation. Nothing like running in circles. I suppose PAM it is, but at this point, I'm just telling my boss it'll have to wait to get this working since it's apparently NOT recommended to use Unix passwords in any form but LDAP based on the warning and recommendations in the documentation. I appreciate all the help, despite the tone to the contrary. - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHfTUAAoJEM/YzwEAv6e7CZ0H/1bZrz62zLCKWblV98O2Pbl4 ZjSWQafFLip8a2GMquZapa59IHUuUwioubmjdhoBwmKM+X3QNy0RHHjzXlVCFHVB nRlnZVE01vy1IZg1IGLlubmqa575JqjZNdXfKnWruX6Vtzh4j15K7RVNwJjwL2GU p4KmxE0IAh+4LTygka80wGDJfKch5iqfd7JkoSUGRzgSsfd2yMR8noX8pRulxUcq gBh/xwh6CRCBBP2/+lNnt88D7NS1YS5z5JZ6EisDJWH7dQZkxlmJ68Dgym3CSJQ3 Uh44pafOzncVytaxO1j3vzRjcy8glWUae2muyp/MT1khGVbJSBu7GnJmyQIiZLY= =+S4G -----END PGP SIGNATURE-----
Hi,
I suppose PAM it is, but at this point, I'm just telling my boss it'll have to wait to get this working since it's apparently NOT recommended to use Unix passwords in any form but LDAP based on the warning and recommendations in the documentation.
rlm_pam module....but you'll be limited to EAP-TTLS/PAP or some other PAP method alan
Mark Haney wrote:
Good lord, this is just getting kinda silly. So, I suppose I can 'chgrp radiusd /etc/shadow' and set read permissions with 'chmod +r /etc/shadow' and have it work, but everything I see says not to do that.
What says not do to that? Not the FreeRADIUS documentation. This is Unix 101. In order for a process to read a file, it must have permission to read the file. So: a) the files permissions have to be changed or b) the processes permissions have to be changed. Pick one. Also, read raddb/radiusd.conf. Look for "shadow". This is documented.
I found a post saying to use the passwd module, but the comments in it say to use either PAM or rlm_unix. I quick check of the comments in rlm_unix say that as of v1.1.0 unix can no longer read of cache /etc/shadow and to use the passwd module.
Phil told you *exactly* how the Unix module works. What's so hard to understand?
That's some crackerjack documentation. Nothing like running in circles.
Only if you're insistent on reading the most nefarious meaning into the text.
I suppose PAM it is, but at this point, I'm just telling my boss it'll have to wait to get this working since it's apparently NOT recommended to use Unix passwords in any form but LDAP based on the warning and recommendations in the documentation.
No, the documentation does NOT say that. You've misunderstood it completely. The warnings have NOTHING to do with the source of the password. FreeRADIUS doesn't care if it's /etc/shadow, LDAP, SQL, or a magic scroll. The warnings have to do with the FORM of the password. "crypted" passwords can't be used with MS-CHAP, PEAP, CHAP, etc. This is a fundamental limitation. It's due to the incompatibilities between the encryption of the password, and the encryption required by the authentication method. The server doesn't work the way you think it works. It works the way it's documented. Most of your frustrations are due to misunderstanding (and misreading) of the text. It's really not rocket science. The unix module calls getspwent(), as Phil said. To do that, the "radiusd" process needs to be able to read /etc/shadow. This is a common problem with shadow passwords going back 15+ years. The solution is simple, and is documented. Alan DeKok.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/14 14:31, Alan DeKok wrote:
The solution is simple, and is documented.
Alan DeKok.
I don't think I've ever flamed anyone in my life, but now I believe I have to. Sadly, it seems like this is a recurring theme with you. I've seen literally DOZENS of posts from you in the archives and through google and in every single one of them there IS NOT a shred of helpful advice except to RTFM. The vaunted documentation is just about the worst I've ever seen. It goes in circles: - From modules/passwd:
# An example configuration for using /etc/passwd. # # We do NOT recommend using the configuration below. See the "unix" # module, or the "pam" module for a cleaner way to get system passwords. # Using this configuration means that the server will find *only* those # passwords which are in /etc/passwd, and will *ignore* all of the # passwords in NIS, LDAP, etc. #
- From modules/unix
unix { # As of 1.1.0, the Unix module no longer reads, # or caches /etc/passwd, /etc/shadow, or /etc/group. # If you wish to cache those files, see the passwd # module.
- From radiusd.conf:
# On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not.
(FWIW, this documentation is beyond incomprehensible. The 'group = shadow' is not about using the group 'shadow' to access /etc/shadow it's changing the group on /etc/shadow to 'radiusd'.) There are a good half dozen archived messages about /etc/shadow and how it is NOT recommended to make such a change. In fact, I found this:
From: "Alan DeKok" <aland at ox.org> To: "FreeRadius users mailing list" <freeradius-users at lists.freeradius.org> Sent: Thursday, January 26, 2006 3:37 PM Subject: Re: Problems System Auth with FreeRadius (/etc/shadow)
"Nataniel Klug" <nata at cnett.psi.br> wrote:
I just have installed the package from Fedora Core 3, nothing else.
Then look at the configuration file. See how it's different from what is shipped with FreeRADIUS.
And setting "a+rw" on /etc/passwd and /etc/shadow is probaby the single worst thing you can do to your system. EVER. Rather than doing that, read raddb/radiusd.conf, it talks about issues with reading /etc/shadow, and describes suggested fixes won't destroy your system.
Honestly, I don't understand why it's so hard to read the configuration files.
Alan DeKok. -
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow. ANYWHERE. PERIOD. (And note, the 'why is it so hard to read the documentation' from you.) In the one post (which I cannot dig up now since I've pulled up so many the last two hours), it's RECOMMENDED not changing read permissions on /etc/shadow. Even though the OP actually got it working that way. And IIRC, it was a reply from you and someone else in the thread that made that recommendation. I have to be honest. I've been doing this a LONG time. 20 years or so. And I've NEVER dealt with a more unprofessional and unhelpful mailing list as I have with this list. What should be a relatively 'simple' solution is anything but with this list. I'm no noob working with linux/unix and text configuration files, and yet I feel FARTHER away from an answer that I did before I started. And due to that 'take two steps forward and half-dozen back', I've made it clear to my boss that FreeRADIUS, while it may work just fine, will be impossible to manage due to the horrible documentation and utter lack of help on the lists. I have removed the packages off my system and will be finding another method of communicating with these switches. I will also be unsubscribing from this list immediately. - -- Mark Haney Network/Systems Administrator Practichem W: (919) 714-8428 Fedora release 20 (Heisenbug) 3.13.4-200.fc20.x86_64 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHg35AAoJEM/YzwEAv6e7MxMIAIEo85oaw7gXyVbbfJa5dzWb 6AjbxxgWQNqmPb2N1LH1VTlrI12eEVoUgx1SwMvqb13h3QXOv8+dDXQxRNvX10Zt IyIw4yQZD3dbqj4yCnljRRvpWZONYts6tdo98LFH7gykBB8XigiaoQCu5oBcYFPf njgwUltA/xlMGdMfCE1+sdIdYe0OvXdGb24assOVtyMFfthWYa3qdFolCapBTmxG lOiCsqSeml68Fz8/uVtzDw5PbbtFpwhsKj81vBcZWm4l5HorvZMG4lRaSnhOHlcP 1uEVqfK69eVvcWVikK1eWeh+k5EHkaMUHjQq4DuAcxE9Xu4AZQKQt3CCTC+HWkQ= =oiap -----END PGP SIGNATURE-----
Mark Haney wrote:
I don't think I've ever flamed anyone in my life, but now I believe I have to.
Good luck.
Sadly, it seems like this is a recurring theme with you. I've seen literally DOZENS of posts from you in the archives and through google and in every single one of them there IS NOT a shred of helpful advice except to RTFM.
Only if you cherry-pick the posts where people ignore the documentation, and I tell them to read it. If you look at the bulk of my posts, it has content, and helps people with real problems. You've just shown your agenda. You don't want to look at facts, you just want to prove I'm bad, and you're better than me.
The vaunted documentation is just about the worst I've ever seen.
Then you haven't been out much. The documentation isn't perfect, but every single configuration item is exhaustively documented. The sad thing is that it doesn't hold your hand. It requires you to put the pieces together yourself, and to do some thinking.
- From radiusd.conf:
# On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not.
(FWIW, this documentation is beyond incomprehensible. The 'group = shadow' is not about using the group 'shadow' to access /etc/shadow it's changing the group on /etc/shadow to 'radiusd'.)
No, you're wrong. The documentation says what it means, and means what it says. I'll explain like you're 5. /etc/shadow is owned by user root, and group shadow. It has "rw" permissions for the user, and "r" permissions for the group. The "other" fields have no permissions, so no one else has permissions to read it. The "group" configuration entry for FreeRADIUS has the documented meaning, which you ignored: # user/group: The name (or #number) of the user/group to run radiusd as. i.e. You can configure FreeRADIUS to run as un-privileged user "radiusd", and group "shadow". So... putting 2 and 2 together, we get 4. Setting "group = shadow" means "run FreeRADIUS as group shadow". Since /etc/shadow can be read by anyone in group "shadow", this means that FreeRADIUS will now be able to read /etc/shadow. See? It's simple. Your interpretation of the documentation is bizarre. Setting "group = shadow" for FreeRADIUS means changing the group of /etc/shadow to "radiusd"? Well, no. The documentation doesn't say that.
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow. ANYWHERE. PERIOD.
It presumes you can put 2 and 2 together. Sadly, you've done that and gotten "purple" instead of "4".
In the one post (which I cannot dig up now since I've pulled up so many the last two hours), it's RECOMMENDED not changing read permissions on /etc/shadow. Even though the OP actually got it working that way. And IIRC, it was a reply from you and someone else in the thread that made that recommendation.
It's not recommended because it's not necessary. If you know nothing about Unix security, you can "chmod 777" all of the files, and get any process to read any file. It will "work", but it won't be secure. Which is why we don't recommend it.
I have to be honest. I've been doing this a LONG time. 20 years or so. And I've NEVER dealt with a more unprofessional and unhelpful mailing list as I have with this list. What should be a relatively 'simple' solution is anything but with this list. I'm no noob working with linux/unix and text configuration files, and yet I feel FARTHER away from an answer that I did before I started.
Perhaps because you read plain english and interpret it in the most bizarre ways. docs: "group = shadow means that FreeRADIUS runs as group shadow" you: OK, "group = shadow" means that /etc/shadow is chgrp to "radiusd" What. The. Heck.
And due to that 'take two steps forward and half-dozen back', I've made it clear to my boss that FreeRADIUS, while it may work just fine, will be impossible to manage due to the horrible documentation and utter lack of help on the lists. I have removed the packages off my system and will be finding another method of communicating with these switches. I will also be unsubscribing from this list immediately.
Have fun. Alan DeKok.
On 10 Mar 2014, at 19:28, Alan DeKok <aland@deployingradius.com> wrote:
So... putting 2 and 2 together, we get 4. Setting "group = shadow" means "run FreeRADIUS as group shadow". Since /etc/shadow can be read by anyone in group "shadow", this means that FreeRADIUS will now be able to read /etc/shadow.
As our friend has unsubscribed, this is mostly for anyone reading the archives. I suspect the problem here is either SELinux or the shadow group not existing. RHEL doesn't have a shadow group by default - as it's a nasty hack and potential source of vulnerability, you're expected to have the sense to create it yourself if its needed. It's also tagged with a unique policy type: [root@orps1 ~]# ls -alZ /etc/shadow ----------. root root system_u:object_r:shadow_t:s0 /etc/shadow Which I *think* would cause an AVC denial. Then there's the small matter of /etc/shadow having no permission mask by default. But someone who's been doing this for a long time would have checked such things, or even provided us with the output of strace, right? :) Regards, Adam Bishop Systems Development Specialist gpg: 0x6609D460 t: +44 (0)1235 822 245 xmpp: adamb@jabber.dev.ja.net Janet, the UK's research and education network. Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238
Adam Bishop wrote:
I suspect the problem here is either SELinux or the shadow group not existing.
Quote possibly.
RHEL doesn't have a shadow group by default - as it's a nasty hack and potential source of vulnerability, you're expected to have the sense to create it yourself if its needed.
That's unfriendly. Oh well.
It's also tagged with a unique policy type:
[root@orps1 ~]# ls -alZ /etc/shadow ----------. root root system_u:object_r:shadow_t:s0 /etc/shadow
Which I *think* would cause an AVC denial.
Yes.
Then there's the small matter of /etc/shadow having no permission mask by default.
Arg. That's Unix 101 debugging, TBH. Track down the root cause of the problem, and fix it.
But someone who's been doing this for a long time would have checked such things, or even provided us with the output of strace, right? :)
Yes. The people who claim decades of experience usually don't follow standard practices. The people who have decades of experience just get follow standard practice, and things done. Alan DeKok.
I don't think I've ever flamed anyone in my life, but now I believe I have to.
Sadly, it seems like this is a recurring theme with you. I've seen literally DOZENS of posts from you in the archives and through google and in every single one of them there IS NOT a shred of helpful advice except to RTFM.
There's usually a good reason for Alan's terse answers.
The vaunted documentation is just about the worst I've ever seen. It goes in circles:
From modules/passwd:
# An example configuration for using /etc/passwd. # # We do NOT recommend using the configuration below. See the "unix" # module, or the "pam" module for a cleaner way to get system passwords. # Using this configuration means that the server will find *only* those # passwords which are in /etc/passwd, and will *ignore* all of the # passwords in NIS, LDAP, etc. #
From modules/unix
Is the reason for not recommending the use of the passwd module applicable here? No. The documentation assumes that you are able to read, interpret, and make your own decisions about the validity of information.
unix { # As of 1.1.0, the Unix module no longer reads, # or caches /etc/passwd, /etc/shadow, or /etc/group. # If you wish to cache those files, see the passwd # module.
So use the passwd module.
From radiusd.conf:
# On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not.
(FWIW, this documentation is beyond incomprehensible. The 'group = shadow' is not about using the group 'shadow' to access /etc/shadow it's changing the group on /etc/shadow to 'radiusd'.)
No. It's about setting the group the FreeRADIUS daemon runs as. The FreeRADIUS daemon does not switch GID or UID when running in debug mode, it continues with the GID and UID of the user which invoked it. That's what the documentation is talking about.
And setting "a+rw" on /etc/passwd and /etc/shadow is probaby the single worst thing you can do to your system.
Yes, setting a+rw would be completely idiotic, if you really don't understand why, you should probably not have permission to make such a change.
EVER.
Rather than doing that, read raddb/radiusd.conf, it talks about issues with reading /etc/shadow, and describes suggested fixes won't destroy your system.
Honestly, I don't understand why it's so hard to read the configuration files.
Agreed.
Alan DeKok. -
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow. ANYWHERE. PERIOD.
Because radiusd.conf is the main configuration file for the server, why would it be cluttered with module specific configuration snippets or advice...
And I've NEVER dealt with a more unprofessional and unhelpful mailing list as I have with this list. What should be a relatively 'simple' solution is anything but with this list. I'm no noob working with linux/unix and text configuration files, and yet I feel FARTHER away from an answer that I did before I started.
And due to that 'take two steps forward and half-dozen back', I've made it clear to my boss that FreeRADIUS, while it may work just fine, will be impossible to manage due to the horrible documentation and utter lack of help on the lists.
An excerpt from the Fedora list: http://marc.info/?l=fedora-list&m=139426697003081&w=2
On 03/06/14 20:22, David Beveridge wrote:
You don't need to lie, or make stuff up, just explain that it IS possible, BUT just not within the timeframe and budget requested.
Thing is, based on my searching, getting FreeRADIUS to work with NIS isn't possible. At least I've found no documentation on how to make it work. There's tons on getting it to work with LDAP, but not NIS. Which is the reason for my OP.
Except for the fact that I already posted here how you can do it... eg: Freeradius supports perl module and perl can do NIS Auth. check out example.pl and then do a google search for "perl NIS" Looks like you're having similar difficulties over there too. --- Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Arran Cudbard-Bell wrote:
An excerpt from the Fedora list:
It's nice to see he's getting the same answers from others. i.e. the problem isn't us.
> Thing is, based on my searching, getting FreeRADIUS to work with NIS > isn't possible. At least I've found no documentation on how to make > it work. There's tons on getting it to work with LDAP, but not NIS. > Which is the reason for my OP.
I fail to see what the problem is. NIS is just a way of adding more back-ends to getpwent() and getspwent(). The applications using those function calls don't need to do anything. i.e. to "integrate" FreeRADIUS with NIS, you just configure NIS. Then, use the "unix" module in FreeRADIUS, in the "authenticate" section. The module will do PAP checks by using getspwent() to get the crypt'd password. *Where* that crypt'd password comes from is for NIS to determine. FreeRADIUS (and the Unix module) doesn't need to do anything. His question amounts to "how do I get FreeRADIUS to read files from MySQL, where MySQL is using ext4 instead of ext3". The answer is "you don't". FreeRADIUS interacts with X, and X does it's magic. What's *behind* X doesn't matter. Either NIS works, and getspwent() returns something useful, or NIS doesn't work, and getspwent() doesn't return anything. Maybe running FreeRADIUS as "root" will help. But if that doesn't work, then the problem is NIS (or something else), *not* FreeRADIUS. And yes, this is one of my common answers. It's why my answers are seen as "unhelpful". I talk about the *cause* of the problem, not the *symptom*. Very often, the cause of the problem is a something external to FreeRADIUS. The symptom is that FreeRADIUS doesn't work the way you want, but that's just a symptom. Sadly, some people *refuse* to understand this. Alan DeKok.
Hi,
I don't think I've ever flamed anyone in my life, but now I believe I have to.
oh..this is going to be interesting... just grabbing the popcorn and cola ready for the show! :-) <snip> oh...that wasnt a flame! disappointed...the rest of the popcron is going away now and the colas going to be flat for when its needed :(
Radiusd.conf DOES NOT talk about issues with reading /etc/shadow. ANYWHERE. PERIOD.
..do you mean this bit of radiusd.conf: # On systems with shadow passwords, you might have to set 'group = shadow' # for the server to be able to read the shadow password file. If you can # authenticate users while in debug mode, but not in daemon mode, it may be # that the debugging mode server is running as a user that can read the # shadow info, and the user listed below can not. ? seems clear to me.
And due to that 'take two steps forward and half-dozen back', I've made it clear to my boss that FreeRADIUS, while it may work just fine,
lets hope I dont come across the contact details for your boss ;-) alan
participants (7)
-
A.L.M.Buxey＠lboro.ac.uk -
Adam Bishop -
Alan DeKok -
Arran Cudbard-Bell -
ktm＠rice.edu -
Mark Haney -
Phil Mayers