Lev Dudko wrote: > Hello Rich, > The answers are below. > > >> Do you have some sort of proxy running? >> netstat -an | grep 9830 >> and >> netstat -an | grep 443 >> >> >> > > No, I have a direct link: > netstat -an | grep 9830 > tcp 0 0 0.0.0.0:9830 0.0.0.0:* > LISTEN > > netstat -an | grep 443 > unix 2 [ ACC ] STREAM LISTENING > 4857378 /tmp/orbit-sherstnv/linc-1d58-0-25f8c4437879e > unix 3 [ ] STREAM CONNECTED 1724431 > when the apache is down (to avoid possible interferences) > > netstat -an | grep 443 > tcp 0 0 :::443 :::* > LISTEN > tcp 0 0 :::8443 :::* > LISTEN > unix 2 [ ACC ] STREAM LISTENING > 4857378 /tmp/orbit-sherstnv/linc-1d58-0-25f8c4437879e > unix 3 [ ] STREAM CONNECTED 1724431 > (apache is up) > > >> What access log level are you using? I suggest using the default. >> >> > > I will check, but I do not remember that I could change the level of > access log, only the error log. > The reason I said is that the access log does not usually log internal operations. > >> [17/Nov/2008:23:43:55 +0300] conn=141 op=1 RESULT err=49 tag=97 >> nentries=0 etime=0 >> >> This usually means "incorrect password". You can verify yourself by >> using ldapsearch: >> ldapsearch -x -D "uid=dudko,ou=People, dc=sinp, dc=msu, dc=ru" -w >> yourpassword -s base -b "" >> >> > I use the same login and password for logging to the system, so I am > sure that it is correct, but in any case the output of the command above > is: > > # extended LDIF > # > # LDAPv3 > # base <> with scope baseObject > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 0 Success > > # numResponses: 1 > > > By the way, the browser which I use to communicate with DSGW is > firefox-3.0.4-1.fc9.x86_64 > and I did not have any problem with translation of my passwords to some > site authorization systems. > Do you have any 8-bit characters in any of your passwords? I wonder if the gateway is corrupting them somehow. > >> If you get err=49 here, this means your password is not correct. >> Agh - my eyes - I think you need to change the errorlog level back to 0 >> - I don't think the problem is ACI related - err=49 means incorrect >> password. >> > > Sorry, I tried to provide all of the information which I have. > > > >> It is a feature. You cannot edit local.conf directly. You have to >> update that information in LDAP. local.conf is a read-only cache of the >> LDAP information. See - >> http://directory.fedoraproject.org/wiki/Howto:AdminServerLDAPMgmt >> > > > Thank you for the explanation, first of all I did it from console, > but with the same result (need to put something in this field to keep > it). In any way I will check again that HOWTO. > Lev > > > >>> On ???, 2008-11-17 at 13:21 -0700, Rich Megginson wrote: >>> >>> >>>> Lev Dudko wrote: >>>> >>>> >>>>> Dear Directory server experts, >>>>> could you help me, please, to solve the problem with DSGW >>>>> authorization. >>>>> I have successfully setup FDS on Fedora 9 with >>>>> setup-ds-admin.pl >>>>> setup ssl with the help of script from this page: >>>>> http://www.linuxmail.info/fedora-directory-server-setup-howto-centos-5/ >>>>> and run setup-ds-dsgw >>>>> Now, the directory server works, administration server works and >>>>> I can configure everything in DS and Admin server with console >>>>> fedora-idm-console -a https://localhost:9830 >>>>> ldap and ldaps ports are open and accept requests. >>>>> >>>>> I can point my browser to https://localhost:9830 and use DSGW to >>>>> search successfully, >>>>> but I can not do authorization, when I try to authorize as some user >>>>> (normal user, Directory Manager or admin) I got the error: >>>>> Authentication Failed >>>>> Authentication failed because the password you supplied is incorrect. >>>>> Please click the Retry button and try again. If you have forgotten the >>>>> password for this entry, a directory administrator must reset the >>>>> password for you. >>>>> >>>>> Of course, I am sure that the password is correct. There are no so much >>>>> useful information in the log files. The >>>>> executable /usr/lib64/dirsrv/dsgw-cgi-bin/doauth do this authorization. >>>>> >>>>> I have read available documentation rather careful, but did not find the >>>>> answer. Looks like one of the solution is to use binddnfile directive >>>>> with special text file, but it looks strange for me that it is >>>>> impossible to use normal authorization in LDAP with DSGW. >>>>> >>>>> Have I missed something during the configuration or forgot to add some >>>>> special ACL? >>>>> >>>>> >>>>> >>>> What platform? >>>> Any information in your admin server logs at /var/log/dirsrv/admin-serv? >>>> >>>> >>>>> Lev >>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> -- >>>>> Fedora-directory-users mailing list >>>>> Fedora-directory-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>>> >>>>> >>>>> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20081117/49e3a95b/attachment.bin