1:34 p.m.
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(a)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(a)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(a)redhat.com> wrote:
>>
>>
>> On 03/11/2015 05:48 PM, prmarino1(a)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....
>>
>> 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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>>
>> --
>> 389 users mailing list
>> 389-users(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-users
1:37 p.m.
New subject: [389-users] GUI console and Kerberos
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(a)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(a)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(a)redhat.com>
wrote:
>>>
>>> On 03/11/2015 05:48 PM, prmarino1(a)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....
>>>
>>> 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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>
>>> --
>>> 389 users mailing list
>>> 389-users(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
1:48 p.m.
New subject: [389-users] GUI console and Kerberos
Ok
I'll do it as soon as as I'm sure Ive got all the ACI's correct.
I think Ill try writing it in markdown I need the practice for some of
my projects on github :)
On Mon, Mar 16, 2015 at 2:37 PM, Mark Reynolds <mareynol(a)redhat.com> wrote:
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(a)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(a)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(a)redhat.com>
>>> wrote:
>>>>
>>>>
>>>> On 03/11/2015 05:48 PM, prmarino1(a)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....
>>>>
>>>> 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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> 389 users mailing list
>>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>
>>>>
>>>> --
>>>> 389 users mailing list
>>>> 389-users(a)lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
3:34 p.m.
New subject: [389-users] GUI console and Kerberos
Whats the policy on including screen shots in case I wanted to include
screen shots from the GUI
I'm guessing they would have to be PNG's based on the wiki howto but
it doesn't specify size limits, and or preferred compression settings,
etc..
On Mon, Mar 16, 2015 at 2:48 PM, Paul Robert Marino <prmarino1(a)gmail.com> wrote:
Ok
I'll do it as soon as as I'm sure Ive got all the ACI's correct.
I think Ill try writing it in markdown I need the practice for some of
my projects on github :)
On Mon, Mar 16, 2015 at 2:37 PM, Mark Reynolds <mareynol(a)redhat.com> wrote:
> 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(a)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(a)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(a)redhat.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 03/11/2015 05:48 PM, prmarino1(a)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....
>>>>>
>>>>> 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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 389 users mailing list
>>>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>
>>>>>
>>>>> --
>>>>> 389 users mailing list
>>>>> 389-users(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>
>> --
>> 389-devel mailing list
>> 389-devel(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
>
> --
> 389-devel mailing list
> 389-devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel
4:56 p.m.
New subject: [389-users] GUI console and Kerberos
On 03/16/2015 02:34 PM, Paul Robert Marino wrote:
Whats the policy on including screen shots in case I wanted to
include
screen shots from the GUI
I'm guessing they would have to be PNG's based on the wiki howto but
it doesn't specify size limits, and or preferred compression settings,
etc..
I don't think there will be a problem if the images correspond to
http://www.port389.org/docs/389ds/administration/screenshots.html
On Mon, Mar 16, 2015 at 2:48 PM, Paul Robert Marino <prmarino1(a)gmail.com> wrote:
> Ok
> I'll do it as soon as as I'm sure Ive got all the ACI's correct.
>
> I think Ill try writing it in markdown I need the practice for some of
> my projects on github :)
>
>
>
> On Mon, Mar 16, 2015 at 2:37 PM, Mark Reynolds <mareynol(a)redhat.com> wrote:
>> 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(a)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(a)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(a)redhat.com>
>>>>> wrote:
>>>>>>
>>>>>> On 03/11/2015 05:48 PM, prmarino1(a)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....
>>>>>>
>>>>>> 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(a)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(a)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(a)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(a)lists.fedoraproject.org
>>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 389 users mailing list
>>>>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>>>>>
https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>> --
>>>>>>> 389 users mailing list
>>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>>>>>
>>>>>> --
>>>>>> 389 users mailing list
>>>>>> 389-users(a)lists.fedoraproject.org
>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users
>>> --
>>> 389-devel mailing list
>>> 389-devel(a)lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>>
>> --
>> 389-devel mailing list
>> 389-devel(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
--
389-devel mailing list
389-devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
3326
days inactive
3326
days old
389-devel@lists.fedoraproject.org
4 comments
3 participants
participants (3)
-
Mark Reynolds -
Paul Robert Marino -
Rich Megginson