Has anyone looked into implementing a Directory Service for PAM (or system) authentication? For apache authorization, I typically use pwauth (which works quite well), and I noticed that there are Apache Directory Services, but it's not possible (as far as I can tell) to leverage pwauth with these. To configure pwauth, the magic occurs in httpd.conf pointing at pwauth - there really is no htpasswd file. Thanks, -Stephen
Hi Stephen, On Jan 10, 2008, at 1:10 PM, Stephen Bowman wrote:
Has anyone looked into implementing a Directory Service for PAM (or system) authentication? For apache authorization, I typically use pwauth (which works quite well), and I noticed that there are Apache Directory Services, but it's not possible (as far as I can tell) to leverage pwauth with these. To configure pwauth, the magic occurs in httpd.conf pointing at pwauth - there really is no htpasswd file.
It is definitely possible to use PAM for authentication, there are PAM bindings for Python, and there is a recent Twisted ticket about adding the necessary implementation for verifying credentials. ( http://twistedmatrix.com/trac/ticket/2970 ) However the IDirectoryService API also handles provisioning, which I don't think PAM exposes. It may however be perfectly acceptable to create a directory service that uses PAM for authentication and either the XML or SQL IDirectoryService for provisioning. Now work has been done in this area however, Apple doesn't use PAM very heavily. But here are some pointers in case someone on the list is interested in contributing. Twisted Cred http://twistedmatrix.com/projects/core/documentation/howto/cred.html (We basically need a new IUsernamePassword supporting ICredentialChecker implementation.) Python PAM binding using Ctypes http://pypi.python.org/pypi/pam/0.1.2 More Python PAM bindings http://pypi.python.org/pypi/spypam/1.0 The IDirectoryService interfaces http://trac.macosforge.org/projects/calendarserver/browser/CalendarServer/tr... It looks like you'll need to override IDirectoryRecord.verifyCredentials on the DirectoryRecord implementation for the service you'd like to use (xmlfile or sqldb should both be possible.) -David
Yes, that is what I thought. I, and I think many many others, would like to use PAM for just the authentication piece, and then fall on another directory service (XML) to do the provisioning. On Jan 10, 2008 5:43 PM, David Reid <dreid@apple.com> wrote:
Hi Stephen,
On Jan 10, 2008, at 1:10 PM, Stephen Bowman wrote:
Has anyone looked into implementing a Directory Service for PAM (or system) authentication? For apache authorization, I typically use pwauth (which works quite well), and I noticed that there are Apache Directory Services, but it's not possible (as far as I can tell) to leverage pwauth with these. To configure pwauth, the magic occurs in httpd.conf pointing at pwauth - there really is no htpasswd file.
It is definitely possible to use PAM for authentication, there are PAM bindings for Python, and there is a recent Twisted ticket about adding the necessary implementation for verifying credentials. ( http://twistedmatrix.com/trac/ticket/2970 ) However the IDirectoryService API also handles provisioning, which I don't think PAM exposes.
It may however be perfectly acceptable to create a directory service that uses PAM for authentication and either the XML or SQL IDirectoryService for provisioning.
Now work has been done in this area however, Apple doesn't use PAM very heavily. But here are some pointers in case someone on the list is interested in contributing.
Twisted Cred http://twistedmatrix.com/projects/core/documentation/howto/cred.html
(We basically need a new IUsernamePassword supporting ICredentialChecker implementation.)
Python PAM binding using Ctypes http://pypi.python.org/pypi/pam/0.1.2
More Python PAM bindings http://pypi.python.org/pypi/spypam/1.0
The IDirectoryService interfaces
http://trac.macosforge.org/projects/calendarserver/browser/CalendarServer/tr...
It looks like you'll need to override IDirectoryRecord.verifyCredentials on the DirectoryRecord implementation for the service you'd like to use (xmlfile or sqldb should both be possible.)
-David
Hi Stephen, --On January 11, 2008 8:26:04 AM -0500 Stephen Bowman <sbbowman@gmail.com> wrote:
Yes, that is what I thought. I, and I think many many others, would like to use PAM for just the authentication piece, and then fall on another directory service (XML) to do the provisioning.
In the short term you can do this: - Configure the server to use the XML accounts. - Then modify/override the twistedcaldav.directory.xmlfile.XMLDirectoryRecord.verifyCredentials method to do the PAM check returning True or False depdning on whether authentication succeeds. In the longer term we need to support a "pluggable" authentication approach. That would probably involve changing the twistedcaldav.directory.directory.DirectoryService.requestAvatarId method to accept "pluggable" credentials checkers. Note that right now we do have that method hard-coded to recognize the Kerberos checker and use that. We just need to generalize that approach. Feel free to tackle that and send in patches if you have time... -- Cyrus Daboo
But to achieve this, the Calendar Server would have to be running as root. The caller of the PAM functions has to be root... I can't think of an easy way around this. Anyone else? On Jan 11, 2008 10:57 AM, Cyrus Daboo <cdaboo@apple.com> wrote:
Hi Stephen,
--On January 11, 2008 8:26:04 AM -0500 Stephen Bowman <sbbowman@gmail.com> wrote:
Yes, that is what I thought. I, and I think many many others, would like to use PAM for just the authentication piece, and then fall on another directory service (XML) to do the provisioning.
In the short term you can do this:
- Configure the server to use the XML accounts. - Then modify/override the twistedcaldav.directory.xmlfile.XMLDirectoryRecord.verifyCredentialsmethod to do the PAM check returning True or False depdning on whether authentication succeeds.
In the longer term we need to support a "pluggable" authentication approach. That would probably involve changing the twistedcaldav.directory.directory.DirectoryService.requestAvatarId method to accept "pluggable" credentials checkers. Note that right now we do have that method hard-coded to recognize the Kerberos checker and use that. We just need to generalize that approach. Feel free to tackle that and send in patches if you have time...
-- Cyrus Daboo
On Jan 11, 2008, at 3:47 PM, Stephen Bowman wrote:
But to achieve this, the Calendar Server would have to be running as root. The caller of the PAM functions has to be root... I can't think of an easy way around this. Anyone else?
Call out to another daemon that ONLY does the PAM function. Let that other program be simple and highly secure, and let it run as root. --- Chris Cleeland
Hi Chris, --On January 11, 2008 5:04:43 PM -0600 Chris Cleeland <chris@milodesigns.com> wrote:
But to achieve this, the Calendar Server would have to be running as root. The caller of the PAM functions has to be root... I can't think of an easy way around this. Anyone else?
Call out to another daemon that ONLY does the PAM function. Let that other program be simple and highly secure, and let it run as root.
Right, that's the right approach. Another option would be to support SASL and then configure PAM into SASL. The CMU SASL does have a saslauthd that runs separately and can do PAM, I believe. You may already be using SASL for other services such as SMTP, IMAP etc. -- Cyrus Daboo
So possibly someone else can benefit from this, here's the final resolution: 1) Installed pwauth (http://unixpapa.com/pwauth/), which is exactly what Chris suggested as a simple highly secure routine to do the PAM authentication. One benefit of pwauth over various others out there is that at compile time you can set the UIDs of the user(s) that can run it. After compiling, the pwauth binary is setuid root so that it can perform the PAM lookups. 2) Following Cyrus's advice, I modified the wistedcaldav.directory.xmlfile.XMLDirectoryRecord.verifyCredentials method as follows: def verifyCredentials(self, credentials): proc1 = subprocess.Popen(["/usr/local/libexec/pwauth"], stdin= subprocess.PIPE, stdout=subprocess.PIPE) proc1.communicate(credentials.username + "\n" + credentials.password+ "\n") returnval = proc1.poll() # A returnval of 0 means a successful authentication, anything else is a failure return returnval == 0 3) Digest HTTP authentication had to be turned OFF, and Basic had to be turned ON in the caldavd.plist configuration file. Now, all users must exist in the XML file for provisioning, but the authentication piece is handled entirely by PAM. If anyone has any problems repeating this, feel free to email me. Thanks, -Stephen On Jan 11, 2008 8:27 PM, Cyrus Daboo <cdaboo@apple.com> wrote:
Hi Chris,
--On January 11, 2008 5:04:43 PM -0600 Chris Cleeland <chris@milodesigns.com> wrote:
But to achieve this, the Calendar Server would have to be running as root. The caller of the PAM functions has to be root... I can't think of an easy way around this. Anyone else?
Call out to another daemon that ONLY does the PAM function. Let that other program be simple and highly secure, and let it run as root.
Right, that's the right approach.
Another option would be to support SASL and then configure PAM into SASL. The CMU SASL does have a saslauthd that runs separately and can do PAM, I believe. You may already be using SASL for other services such as SMTP, IMAP etc.
-- Cyrus Daboo
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
Stephen, Can you file a ticket in Trac, including this code? That way it's on our list to integrate this into the server. Thanks, -wsv On Jan 12, 2008, at 11:18 AM, Stephen Bowman wrote:
So possibly someone else can benefit from this, here's the final resolution:
1) Installed pwauth (http://unixpapa.com/pwauth/), which is exactly what Chris suggested as a simple highly secure routine to do the PAM authentication. One benefit of pwauth over various others out there is that at compile time you can set the UIDs of the user(s) that can run it. After compiling, the pwauth binary is setuid root so that it can perform the PAM lookups.
2) Following Cyrus's advice, I modified the wistedcaldav.directory .xmlfile.XMLDirectoryRecord.verifyCredentials method as follows:
def verifyCredentials(self, credentials): proc1 = subprocess.Popen(["/usr/local/libexec/pwauth"], stdin=subprocess.PIPE, stdout=subprocess.PIPE) proc1.communicate(credentials.username + "\n" + credentials.password + "\n") returnval = proc1.poll() # A returnval of 0 means a successful authentication, anything else is a failure return returnval == 0
3) Digest HTTP authentication had to be turned OFF, and Basic had to be turned ON in the caldavd.plist configuration file.
Now, all users must exist in the XML file for provisioning, but the authentication piece is handled entirely by PAM.
If anyone has any problems repeating this, feel free to email me.
Thanks, -Stephen
On Jan 11, 2008 8:27 PM, Cyrus Daboo <cdaboo@apple.com> wrote: Hi Chris,
--On January 11, 2008 5:04:43 PM -0600 Chris Cleeland <chris@milodesigns.com> wrote:
But to achieve this, the Calendar Server would have to be running as root. The caller of the PAM functions has to be root... I can't think of an easy way around this. Anyone else?
Call out to another daemon that ONLY does the PAM function. Let that other program be simple and highly secure, and let it run as root.
Right, that's the right approach.
Another option would be to support SASL and then configure PAM into SASL. The CMU SASL does have a saslauthd that runs separately and can do PAM, I believe. You may already be using SASL for other services such as SMTP, IMAP etc.
-- Cyrus Daboo
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
_______________________________________________ calendarserver-users mailing list calendarserver-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/calendarserver-users
participants (5)
-
Chris Cleeland
-
Cyrus Daboo
-
David Reid
-
Stephen Bowman
-
Wilfredo Sánchez Vega