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@xxxxxxxxxx> wrote: > > > On 03/11/2015 05:48 PM, prmarino1@xxxxxxxxx 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: 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@xxxxxxxxx> >> 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@xxxxxxxxx> >>> 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@xxxxxxxxxx> >>>> 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@xxxxxxxxxxxxxxxxxxxxxxx >>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>>>> >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >> >> -- >> 389 users mailing list >> 389-users@xxxxxxxxxxxxxxxxxxxxxxx >> https://admin.fedoraproject.org/mailman/listinfo/389-users > > > -- > 389 users mailing list > 389-users@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-users -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
