Richard Megginson wrote: > Nicholas Byrne wrote: >> Firstly, thanks for your help. Responding inline below - >> >> Richard Megginson wrote: >>> Nicholas Byrne wrote: >>>> Hi, >>>> >>>> With FDS 1.0.2, I've followed the configuration howto guide lines >>>> to setup the Directory Server to use SSL (as per my post a few days >>>> ago) however after configuring the Administration Server and >>>> Console to use SSL as well i've run into trouble. The directory >>>> server alone works fine with SSL. >>>> >>>> The reason i'm trying to get Admin and console working in SSL is so >>>> i can setup a secure windows sync agreement, without this all i can >>>> do is setup a insecure sync agreement. >>> But you don't have to get Admin and console working with SSL in >>> order to set up a windows sync agreement with SSL. Do the docs say >>> you have to do this? If so, where? >> No the docs don't say that explicitly but when setting up a windows >> sync agreement it doesn't give you the option of changing the >> supplier - it is set to "ds01.tech:389". > > That's just the label it uses for that particular server in the > console. It really uses ldaps if you configure it to, even though it > shows the non-secure port for the label in the console. This is > merely used to identify the server. This is a well known source of > confusion. > >> The Windows side of the connection is fine as i can specify the >> connection details. I was following the guide at >> http://www.redhat.com/docs/manuals/dir-server/ag/7.1/sync.html#2859728 >> and the image under "step 6" indicates the supplier should be >> configured as port 636. >> >> I am new to this, so i may have got confused but i thought passwords >> won't be syncronised unless the FDS supplier and the Windows AD >> Server are set to use SSL/636. I also realise password changes won't >> be synced unless passsync is installed and configured on the AD side, >> but right now thats not necessary as i just want to get basics working. > > You can use passsync without SSL for testing purposes, but do not do > this in production. This is incorrect. PassSync requires SSL to work. If SSL is not configured, PassSync will report errors in it's log file stating that SSL is required. -NGK > >> >>>> >>>> The console will not display anything (absolutely no screen or >>>> anything) after entering password and clicking OK in the >>>> authentication dialog. There are no messages in the console i >>>> started it on. >>> startconsole -D will give you debug information, and startconsole -D >>> 9 will give you everything. >>>> >>>> Before i configured the SSL on the admin server and console it was >>>> working correctly and displayed the normal Admin server/Directory >>>> Server screens. >>>> >>>> The console which i'm running using (i also tried admin user): >>>> >>>> startconsole -u "cn=Directory Manager" -a https://ds01.tech:59910 >>>> -x nologo >>>> >>>> I turned loglevel to debug in the admin server and this is what i see: >>>> >>>> [Tue Nov 28 14:22:46 2006] [info] Connection to child 30 >>>> established (server ds01.tech:443, client 10.170.99.22) >>>> [Tue Nov 28 14:22:47 2006] [notice] [client 10.170.99.22] >>>> admserv_host_ip_check: ap_get_remote_host could not resolve >>>> 10.170.99.22 >>>> [Tue Nov 28 14:22:47 2006] [info] Initial (No.1) HTTPS request >>>> received for child 30 (server ds01.tech:443) >>>> [Tue Nov 28 14:22:47 2006] [debug] mod_admserv.c(2518): [client >>>> 10.170.99.22] checking user cache for: cn=Directory Manager >>>> [Tue Nov 28 14:22:47 2006] [debug] mod_admserv.c(2525): [client >>>> 10.170.99.22] not in cache, trying DS >>>> [Tue Nov 28 14:22:47 2006] [debug] mod_admserv.c(1480): [client >>>> 10.170.99.22] admserv_check_authz: request for uri >>>> [/admin-serv/authenticate] >>>> [Tue Nov 28 14:22:47 2006] [notice] [client 10.170.99.22] >>>> admserv_check_authz(): passing [/admin-serv/authenticate] to the >>>> userauth handler >>>> [Tue Nov 28 14:22:47 2006] [info] Connection to child 30 closed >>>> (server ds01.tech:443, client 10.170.99.22) >>> This looks ok, except for the log shows port 443 and you are using >>> port 59910. >> Is there a way to fix this? If i'm using https that implies 443 but >> specifying the port 59910, which has precedence - i assume the the >> port. If i use http and port 59910 the console with debug shows the >> server fails to respond: > Right. https tells it to use HTTP over SSL, and the port specifies > which port the server is listening on. When you configure the Admin > Server to use SSL, you can no longer use HTTP - you must use HTTPS. > The admin server doesn't listen to both a non-secure port and a secure > port, as does the directory server. >> >> CommManager> New CommRecord >> (http://ds01.tech:59910/admin-serv/authenticate) >> http://ds01.tech:59910/[0:0] open> Ready >> http://ds01.tech:59910/[0:0] accept> >> http://ds01.tech:59910/admin-serv/authenticate >> http://ds01.tech:59910/[0:0] send> GET \ >> http://ds01.tech:59910/[0:0] send> /admin-serv/authenticate \ >> http://ds01.tech:59910/[0:0] send> HTTP/1.0 >> http://ds01.tech:59910/[0:0] send> Host: ds01.tech:59910 >> http://ds01.tech:59910/[0:0] send> Connection: Keep-Alive >> http://ds01.tech:59910/[0:0] send> User-Agent: >> Fedora-Management-Console/1.0 >> http://ds01.tech:59910/[0:0] send> Accept-Language: en >> http://ds01.tech:59910/[0:0] send> Authorization: Basic \ >> http://ds01.tech:59910/[0:0] send> <removed> \ >> http://ds01.tech:59910/[0:0] send> >> http://ds01.tech:59910/[0:0] send> >> >> With https, i get to through the authentication stage at least. >>>> >>>> In the slapd log i see: >>>> >>>> [28/Nov/2006:14:22:46 +0000] conn=51 fd=65 slot=65 SSL connection >>>> from 10.170.99.22 to 10.103.20.21 >>>> [28/Nov/2006:14:22:46 +0000] conn=51 SSL 128-bit RC4 >>>> [28/Nov/2006:14:22:46 +0000] conn=51 op=0 BIND dn="cn=Directory >>>> Manager" method=128 version=3 >>>> [28/Nov/2006:14:22:46 +0000] conn=51 op=0 RESULT err=0 tag=97 >>>> nentries=0 etime=0 dn="cn=directory manager" >>> This looks like the /admin-serv/authenticate request as logged in >>> the admin server. >>>> [28/Nov/2006:14:22:46 +0000] conn=52 fd=64 slot=64 SSL connection >>>> from 10.170.99.22 to 10.103.20.21 >>>> [28/Nov/2006:14:32:04 +0000] conn=52 op=-1 fd=64 closed - >>>> Encountered end of file. >>> This looks like the console is attempting to use ldap on the ldaps >>> port. I think you need to tell the console to use SSL when talking >>> to this directory server - >>> http://directory.fedora.redhat.com/wiki/Howto:SSL#Using_the_command_line >>> >> I ran through that part of the howto, here is the output below and as >> you can see " nsServerSecurity" is set to on (i assume this is the >> bit you mean?) - > Yes. So now attempt to restart the admin server and restart the > console, using the https:// URL. >> >> [nick at nblap ~]$ ldapsearch -x -D "cn=directory manager" -W -b >> o=netscaperoot "nsServerID=slapd-ds01" >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base <o=netscaperoot> with scope subtree >> # filter: nsServerID=slapd-ds01 >> # requesting: ALL >> # >> >> # slapd-ds01, Fedora Directory Server, Server Group, ds01.tech, tech, >> Netscap >> eRoot >> dn: cn=slapd-ds01, cn=Fedora Directory Server, cn=Server Group, >> cn=ds01.tech, >> ou=tech, o=NetscapeRoot >> objectClass: netscapeServer >> objectClass: nsDirectoryServer >> objectClass: nsResourceRef >> objectClass: nsConfig >> objectClass: groupOfUniqueNames >> objectClass: top >> nsServerSecurity: on >> nsServerID: slapd-ds01 >> nsBindDN: cn=Directory Manager >> nsBaseDN: dc=tech >> serverRoot: /opt/fedora-ds >> nsServerPort: 389 >> nsSecureServerPort: 636 >> serverProductName: Directory Server (ds01) >> serverVersionNumber: 1.0.2 >> installationTimeStamp: 20061121103832Z >> nsSuiteSpotUser: ldap >> serverHostName: ds01.tech >> cn: slapd-ds01 >> uniqueMember: cn=slapd-ds01, cn=Fedora Directory Server, cn=Server >> Group, cn=d >> s01.tech, ou=tech, o=NetscapeRoot >> uniqueMember: cn=admin-serv-ds01, cn=Fedora Administration Server, >> cn=Server G >> roup, cn=ds01.tech, ou=tech, o=NetscapeRoot >> userPassword:: <removed> >> >>>> >>>> Anyone know how i can fix this? Thanks very much >>>> Nick >>>> >>>> >>>> >>>> >>>> This e-mail is the property of Quadriga Worldwide Ltd, intended for >>>> the addressee only and confidential. Any dissemination, copying or >>>> distribution of this message or any attachments is strictly >>>> prohibited. >>>> >>>> If you have received this message in error, please notify us >>>> immediately by replying to the message and deleting it from your >>>> computer. >>>> >>>> Messages sent to and from Quadriga may be monitored. >>>> >>>> Quadriga cannot guarantee any message delivery method is secure or >>>> error-free. Information could be intercepted, corrupted, lost, >>>> destroyed, arrive late or incomplete, or contain viruses. >>>> >>>> We do not accept responsibility for any errors or omissions in this >>>> message and/or attachment that arise as a result of transmission. >>>> >>>> You should carry out your own virus checks before opening any >>>> attachment. >>>> >>>> Any views or opinions presented are solely those of the author and >>>> do not necessarily represent those of Quadriga. >>>> >>>> -- >>>> Fedora-directory-users mailing list >>>> Fedora-directory-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> ------------------------------------------------------------------------ >>> >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >> >> >> >> This e-mail is the property of Quadriga Worldwide Ltd, intended for >> the addressee only and confidential. Any dissemination, copying or >> distribution of this message or any attachments is strictly prohibited. >> >> If you have received this message in error, please notify us >> immediately by replying to the message and deleting it from your >> computer. >> >> Messages sent to and from Quadriga may be monitored. >> >> Quadriga cannot guarantee any message delivery method is secure or >> error-free. Information could be intercepted, corrupted, lost, >> destroyed, arrive late or incomplete, or contain viruses. >> >> We do not accept responsibility for any errors or omissions in this >> message and/or attachment that arise as a result of transmission. >> >> You should carry out your own virus checks before opening any >> attachment. >> >> Any views or opinions presented are solely those of the author and do >> not necessarily represent those of Quadriga. >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > ------------------------------------------------------------------------ > > -- > 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: 3241 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20061128/3fc3ffb1/attachment.bin
