<div dir="ltr">Hi Paul,<div><br></div><div>I'd be interested in taking a look at it and I'm sure someone else out there would as well.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 16, 2015 at 2:34 PM, Paul Robert Marino <span dir="ltr"><<a href="mailto:prmarino1@gmail.com" target="_blank">prmarino1@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Is there any interest in me writing a howto on this?<br>
keep in mind it doesn't break any of the built in functionality but<br>
just adds the ability to grant users admin privileges and log into the<br>
the GUI console (389-console) using their Kerberos password which are<br>
not stored in the LDAP database.<br>
<br>
<br>
<br>
<br>
On Sun, Mar 15, 2015 at 4:52 PM, Paul Robert Marino <<a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a>> wrote:<br>
> I got it working Kerberos 5 authentication in 389-console for standard<br>
> user accounts.<br>
> none of the users Ive tested with have password fields in the LDAP<br>
> database they are only authenticating via Kerberos through PAM. why is<br>
> this a big deal the 389-console does not support SASL so GSSAPI<br>
> doesn't work either.<br>
><br>
><br>
><br>
> I had to implement mod_auth_pam "yum install -y mod_auth_pam.x86_64"<br>
> Then I had to configure pam_passthru<br>
> <a href="http://www.port389.org/docs/389ds/howto/howto-pam-pass-through.html" target="_blank">http://www.port389.org/docs/389ds/howto/howto-pam-pass-through.html</a><br>
> (by the way I have some notes on things that should be revised on that<br>
> page)<br>
> Then I had to modify two config files. listed below in unified diffs<br>
> next there are several ACI's that needed to be altered to provide the<br>
> users with the required permissions those I'm still working out.<br>
><br>
> here are the two files that need to be modified<br>
> "<br>
> --- /etc/dirsrv/admin-serv/httpd.conf.bak 2013-08-20<br>
> 15:34:35.000000000 -0400<br>
> +++ /etc/dirsrv/admin-serv/httpd.conf 2015-03-15 13:59:05.431490104 -0400<br>
> @@ -134,6 +134,9 @@<br>
> LoadModule restartd_module /usr/lib64/dirsrv/modules/mod_restartd.so<br>
> LoadModule nss_module /usr/lib64/httpd/modules/libmodnss.so<br>
> LoadModule admserv_module /usr/lib64/dirsrv/modules/mod_admserv.so<br>
> +LoadModule auth_pam_module /usr/lib64/httpd/modules/mod_auth_pam.so<br>
> +LoadModule auth_sys_group_module /usr/lib64/httpd/modules/mod_auth_sys_group.so<br>
> +<br>
><br>
> ### Section 2: 'Main' server configuration<br>
> #<br>
> "<br>
> "<br>
> --- /etc/dirsrv/admin-serv/admserv.conf.bak 2013-08-20<br>
> 15:34:35.000000000 -0400<br>
> +++ /etc/dirsrv/admin-serv/admserv.conf 2015-03-15 12:45:38.906535271 -0400<br>
> @@ -74,6 +74,8 @@<br>
> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
> AuthType basic<br>
> AuthName "Admin Server"<br>
> + AuthPAM_Enabled on<br>
> + AuthPAM_FallThrough on<br>
> Require valid-user<br>
> Order allow,deny<br>
> Allow from all<br>
> @@ -84,6 +86,8 @@<br>
> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
> AuthType basic<br>
> AuthName "Admin Server"<br>
> + AuthPAM_Enabled on<br>
> + AuthPAM_FallThrough on<br>
> Require valid-user<br>
> AdminSDK on<br>
> ADMCgiBinDir /usr/lib64/dirsrv/cgi-bin<br>
> @@ -97,6 +101,8 @@<br>
> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
> AuthType basic<br>
> AuthName "Admin Server"<br>
> + AuthPAM_Enabled on<br>
> + AuthPAM_FallThrough on<br>
> Require valid-user<br>
> AdminSDK on<br>
> ADMCgiBinDir /usr/lib64/dirsrv/cgi-bin<br>
> @@ -111,6 +117,8 @@<br>
> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
> AuthType basic<br>
> AuthName "Admin Server"<br>
> + AuthPAM_Enabled on<br>
> + AuthPAM_FallThrough on<br>
> Require valid-user<br>
> Order allow,deny<br>
> Allow from all<br>
> @@ -123,6 +131,8 @@<br>
> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
> AuthType basic<br>
> AuthName "Admin Server"<br>
> + AuthPAM_Enabled on<br>
> + AuthPAM_FallThrough on<br>
> Require valid-user<br>
> ## turn off the password pipe when using mod_restartd<br>
> AdminSDK off<br>
><br>
> "<br>
><br>
> On Sun, Mar 15, 2015 at 12:39 PM, Paul Robert Marino<br>
> <<a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a>> wrote:<br>
>> No thats not it at all. that already works for users authenticating<br>
>> via SASL GSSAPI<br>
>> This is a legacy LDAPv2 simple bind with TLS instead of SSL.<br>
>> SASL does not apply here from what I can see.<br>
>> it looks like the username and password are being passed but with the<br>
>> the kerberos principal as the username. so instead I'm going to<br>
>> reattempt this via an other route utilizing PAM.<br>
>><br>
>><br>
>><br>
>><br>
>> On Fri, Mar 13, 2015 at 11:58 AM, Mark Reynolds <<a href="mailto:mareynol@redhat.com">mareynol@redhat.com</a>> wrote:<br>
>>><br>
>>><br>
>>> On 03/11/2015 05:48 PM, <a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a> wrote:<br>
>>>><br>
>>>> Update I got pulled away on something else but there is progress.<br>
>>>><br>
>>>> I tried the Apache Kerberos 5 auth module initial auth worked but then it<br>
>>>> went back to LDAP error 32 because it looks like it passed<br>
>>>> <username>@<realm> to the ldap server as the username. Which is something I<br>
>>>> knew the module did from past experience with it.<br>
>>><br>
>>> You probably just need to setup your sasl mappings in the Directory Server:<br>
>>><br>
>>> <a href="https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/configuring-sasl-id-mapping.html" target="_blank">https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/configuring-sasl-id-mapping.html</a><br>
>>><br>
>>> Mark<br>
>>><br>
>>>><br>
>>>> I'm going to pick this up again tomorrow morning but I think I have it<br>
>>>> now I think I have a plan that will work.<br>
>>>><br>
>>>> I'm going to try the apache Pam authentication module which should pass<br>
>>>> the username along without modification. Then I will configure Pam pass<br>
>>>> through in 389 server. If I'm right this may do it. As a hacked method.<br>
>>>> Then if I get it working and people are interested I can write a mini<br>
>>>> howto.<br>
>>>> That said if it works it will require a litle more research but I may be<br>
>>>> able to write a simple to implement RFE so it can attempt GSSAPI auth<br>
>>>> possibly based on a configuration parameter.<br>
>>>><br>
>>>> Sent from my BlackBerry 10 smartphone.<br>
>>>> Original Message<br>
>>>> From: Paul Robert Marino<br>
>>>> Sent: Wednesday, March 11, 2015 15:06<br>
>>>> To: General discussion list for the 389 Directory server project.<br>
>>>> Subject: Re: [389-users] GUI console and Kerberos<br>
>>>><br>
>>>> correction it looks like I will need to enable either PAM passthrough<br>
>>>> or I once i actually configure the real kerberos auth via the module<br>
>>>> an not my quick test hack<br>
>>>> I think it may allow forwarding the key via SASL GSSAPI<br>
>>>> but either way this is good I think im well on my way to figuring it out.<br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Wed, Mar 11, 2015 at 2:51 PM, Paul Robert Marino <<a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a>><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Ok so here is some progress<br>
>>>>> i manually added my user name and password in<br>
>>>>> /etc/dirsrv/admin-serv/admpw using the htpassword command<br>
>>>>> if i put cn=<username> I get ldap error 32: No such object in the<br>
>>>>> admin server error log<br>
>>>>> but if i just put my username in it finds the entry and i get a<br>
>>>>> different error ldap error 48: Inappropriate authentication<br>
>>>>> this is making me wonder if saslauthd may help<br>
>>>>><br>
>>>>> On Wed, Mar 11, 2015 at 2:34 PM, Paul Robert Marino <<a href="mailto:prmarino1@gmail.com">prmarino1@gmail.com</a>><br>
>>>>> wrote:<br>
>>>>>><br>
>>>>>> I know it will probably be a little more complex than that but I think<br>
>>>>>> it logically should be one of the steps.<br>
>>>>>> although it doesn't explain how "cn=Directory Manager" works<br>
>>>>>> but it makes a lot of sense when you see the 401 error from the login<br>
>>>>>> attempt it comes from the directory specified by<br>
>>>>>> "<br>
>>>>>> <Location /admin-serv/authenticate><br>
>>>>>> SetHandler user-auth<br>
>>>>>> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
>>>>>> AuthType basic<br>
>>>>>> AuthName "Admin Server"<br>
>>>>>> Require valid-user<br>
>>>>>> Order allow,deny<br>
>>>>>> Allow from all<br>
>>>>>> </Location><br>
>>>>>> "<br>
>>>>>> in /etc/dirsrv/admin-serv/admserv.conf<br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>><br>
>>>>>> On Wed, Mar 11, 2015 at 2:13 PM, Rich Megginson <<a href="mailto:rmeggins@redhat.com">rmeggins@redhat.com</a>><br>
>>>>>> wrote:<br>
>>>>>>><br>
>>>>>>> On 03/11/2015 11:54 AM, Paul Robert Marino wrote:<br>
>>>>>>>><br>
>>>>>>>> Hey every one<br>
>>>>>>>> I have a question I know at least once in the past i setup the admin<br>
>>>>>>>> console so it could utilize Kerberos passwords based on a howto I<br>
>>>>>>>> found once which after I changed jobs I could never find again.<br>
>>>>>>>><br>
>>>>>>>> today I was looking for something else and I saw a mention on the site<br>
>>>>>>>> about httpd needing to be compiled with http auth support.<br>
>>>>>>>> well I did a little digging and I found this file<br>
>>>>>>>> /etc/dirsrv/admin-serv/admserv.conf<br>
>>>>>>>><br>
>>>>>>>> in that file I found a lot of entries that look like this<br>
>>>>>>>> "<br>
>>>>>>>> <LocationMatch /*/[tT]asks/[Cc]onfiguration/*><br>
>>>>>>>> AuthUserFile /etc/dirsrv/admin-serv/admpw<br>
>>>>>>>> AuthType basic<br>
>>>>>>>> AuthName "Admin Server"<br>
>>>>>>>> Require valid-user<br>
>>>>>>>> AdminSDK on<br>
>>>>>>>> ADMCgiBinDir /usr/lib64/dirsrv/cgi-bin<br>
>>>>>>>> NESCompatEnv on<br>
>>>>>>>> Options +ExecCGI<br>
>>>>>>>> Order allow,deny<br>
>>>>>>>> Allow from all<br>
>>>>>>>> </LocationMatch><br>
>>>>>>>><br>
>>>>>>>> "<br>
>>>>>>>> when I checked /etc/dirsrv/admin-serv/admpw sure enough I found the<br>
>>>>>>>> Password hash for the admin user.<br>
>>>>>>>><br>
>>>>>>>> So my question is before I wast time experimenting could it possibly<br>
>>>>>>>> be as simple as changing the auth type to kerberos<br>
>>>>>>>> <a href="http://modauthkerb.sourceforge.net/configure.html" target="_blank">http://modauthkerb.sourceforge.net/configure.html</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> I don't know. I don't think anyone has ever tried it.<br>
>>>>>>><br>
>>>>>>>> keep in mind my Kerberos Servers do not use LDAP as the backend.<br>
>>>>>>>> --<br>
>>>>>>>> 389 users mailing list<br>
>>>>>>>> <a href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
>>>>>>>> <a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>> --<br>
>>>>>>> 389 users mailing list<br>
>>>>>>> <a href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
>>>>>>> <a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
>>>><br>
>>>> --<br>
>>>> 389 users mailing list<br>
>>>> <a href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
>>>> <a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
>>><br>
>>><br>
>>> --<br>
>>> 389 users mailing list<br>
>>> <a href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
>>> <a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a><br>
--<br>
389 users mailing list<br>
<a href="mailto:389-users@lists.fedoraproject.org">389-users@lists.fedoraproject.org</a><br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/389-users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/389-users</a></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Ted Strother<br>Systems Administrator Senior<br>Information Technology Services<br>University of Michigan-Dearborn<br>19000 Hubbard Drive, 238 FCN<br>Dearborn, MI 48126</div>
</div>