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.