[389-devel] [389-users] GUI console and Kerberos

Mark Reynolds mareynol at redhat.com
Mon Mar 16 18:37:02 UTC 2015


Absolutely!

You can either write a simple doc, and I will port it to MarkDown and 
put it on the wiki, or you can write it in MarkDown:

http://www.port389.org/docs/389ds/howto/howto-write-wiki-page.html

Thanks,
Mark

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



More information about the 389-devel mailing list