Authenticating CHAP-Password to Pam (Kerberos 5 to AD)
Please tell me someone has fixed this problem. I'm trying to authenticate an Ascend MAX dial-up server back to Windows Active Directory. I am using a local unix group for authorization. I have Pam set up on my system and it uses Kerberos 5 to authenticate to AD just fine. But I'm getting: auth: type "PAM" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_pam: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". modcall[authenticate]: module "pam" returns invalid for request 0 I did some checking and found this posting from 2003 basically saying it can't be done: http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg19439.html I do have other options other than the Windows Domain authentication, but I was not wanting to pursue them unless I had to. Has this been solved or am I SOL? Patrick
Patrick Bartkus wrote:
Please tell me someone has fixed this problem.
I'm trying to authenticate an Ascend MAX dial-up server back to Windows Active Directory.
I am using a local unix group for authorization.
I have Pam set up on my system and it uses Kerberos 5 to authenticate to AD just fine.
But I'm getting: auth: type "PAM" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_pam: Attribute "User-Password" is required for authentication. Cannot use "CHAP-Password". modcall[authenticate]: module "pam" returns invalid for request 0
I did some checking and found this posting from 2003 basically saying it can't be done: http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg19439.html
I do have other options other than the Windows Domain authentication, but I was not wanting to pursue them unless I had to.
Has this been solved or am I SOL?
It is not a code bug. It is a fundamental feature of the algorithm. It *cannot* be solved. You are, as you put it, SOL.
Phil, Thanks. In another thread I read, you wrote: --- The MS-CHAP module requires either the MD4-based NT password hash, the plaintext password from which it can derive the NT has, or callout to Samba & domain membership. --- Does this mean that if I setup Samba on this box, get it to be a member of the domain exchanging Domain UIDs and passwords, I could then authenticate to Samba from my MS-CHAP-speaking NAS? BTW, for any non-native English speakers, if you want the definition of SOL, e-mail me privately and I'll explain. Patrick On 1/27/06, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Patrick Bartkus wrote:
Has this been solved or am I SOL?
It is not a code bug. It is a fundamental feature of the algorithm. It *cannot* be solved. You are, as you put it, SOL.
Patrick Bartkus wrote:
Phil,
Thanks.
In another thread I read, you wrote: --- The MS-CHAP module requires either the MD4-based NT password hash, the plaintext password from which it can derive the NT has, or callout to Samba & domain membership. ---
Does this mean that if I setup Samba on this box, get it to be a member of the domain exchanging Domain UIDs and passwords, I could then authenticate to Samba from my MS-CHAP-speaking NAS?
Yes. See the "ntlm_auth" option of the "mschap" module. You need winbind (and therefore Samba 3) but it's pretty trivial to setup.
Patrick Bartkus <patrckb@gmail.com> wrote:
Does this mean that if I setup Samba on this box, get it to be a member of the domain exchanging Domain UIDs and passwords, I could then authenticate to Samba from my MS-CHAP-speaking NAS?
Possible. If it's an NT domain. If it's an Active Directory domain, then no, it's still impossible. Maybe Samba4 (when it's done) will allow this. Alan DeKok.
Alan DeKok wrote:
Patrick Bartkus <patrckb@gmail.com> wrote:
Does this mean that if I setup Samba on this box, get it to be a member of the domain exchanging Domain UIDs and passwords, I could then authenticate to Samba from my MS-CHAP-speaking NAS?
Possible. If it's an NT domain.
If it's an Active Directory domain, then no, it's still impossible. Maybe Samba4 (when it's done) will allow this.
I'm confused - I and many people are doing MS-CHAP to an AD domain with samba3, winbind and the ntlm_auth helper - what are you referring to that doesn't work that samba4 would change?
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I'm confused - I and many people are doing MS-CHAP to an AD domain with samba3, winbind and the ntlm_auth helper - what are you referring to that doesn't work that samba4 would change?
Yes, they're using the old-style NT4 logins. So MS-CHAP works. Samba4 *may* allow pulling clear-text passwords from AD, in which case CHAP will work, too. Alan DeKok.
Alan DeKok wrote:
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
I'm confused - I and many people are doing MS-CHAP to an AD domain with samba3, winbind and the ntlm_auth helper - what are you referring to that doesn't work that samba4 would change?
Yes, they're using the old-style NT4 logins. So MS-CHAP works.
Ah I see. I had read the message differently - though the posters original question (and the subject line unhelpfully) was about CHAP his subsequent query referenced another thread and mentioned MS-CHAP. You're right that no current software can perform CHAP against AD except IAS running on a domain controller against accounts with reversible encryption enabled (see below).
Samba4 *may* allow pulling clear-text passwords from AD, in which case CHAP will work, too.
Why would samba4 be any different that samba3 in that regard? I assume we are talking about the same thing (samba as a member server with a "real" microsoft PDC) in which case the code that would need adding would be an API on the windows side - AD realms (in fact NT domains all the way back to NT4 IIRC) can already store the password in "reversibly encrypted" plaintext to support CHAP (only via IAS and only running on the physical PDC) or Digest MD5 on HTTP.
Phil Mayers <p.mayers@imperial.ac.uk> wrote:
Why would samba4 be any different that samba3 in that regard?
Because Samba4 will be a full-fledged AD domain member. Samba3 is a second-class citizen of an AD domain, as it implements NT domains.
I assume we are talking about the same thing (samba as a member server with a "real" microsoft PDC) in which case the code that would need adding would be an API on the windows side - AD realms (in fact NT domains all the way back to NT4 IIRC) can already store the password in "reversibly encrypted" plaintext to support CHAP (only via IAS and only running on the physical PDC) or Digest MD5 on HTTP.
Yes. And once Samba4 is a full-fledged member of an AD domain, the other AD servers will happily replicate data to it... including the clear-text password. Samba4 can then expose it in the userPassword field. The reason IAS works is that it does super-secret magic Microsoft calls that no one has figured out. If Samba4 is a member of the AD domain, it doesn't have to figure out those calls. Alan DeKok.
Yes. And once Samba4 is a full-fledged member of an AD domain, the other AD servers will happily replicate data to it... including the clear-text password. Samba4 can then expose it in the userPassword field.
Ah, so samba4 as a PDC rather than member server, peering with microsoft PDCs. That is an option I had not considered, and is certainly an interesting possibility, though still dependent on the per-account or whole-domain setting and a password change.
The reason IAS works is that it does super-secret magic Microsoft calls that no one has figured out. If Samba4 is a member of the AD domain, it doesn't have to figure out those calls.
Indeed.
participants (3)
-
Alan DeKok -
Patrick Bartkus -
Phil Mayers