Hi If I set nsslapd-allow-anonymous-access: off I am not able to login to the 389-console. I can remedy this by checking the checkbox "Use SSL in Console" in the Encryption tab on the Directory Server console. This seems a strange solution to the problem. Why would disabing anonymous access break console access and why would enabling "Use SSL in Console" fix it?
I get another interesting error as well with the "Use SSL in Console" checkbox checked. Login to Management Console Open Directory Console Click on Configuration tab Click on Encryption tab
I get "An error has occured" Could not open file(null). File does not exist or filename is invalid.
After I click on OK, I can proceed to the Encryption tab. Is this a bug or me not configuring something. The error message is not very helpfull.
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
Gerrard Geldenhuis wrote:
Hi If I set nsslapd-allow-anonymous-access: off I am not able to login to the 389-console. I can remedy this by checking the checkbox "Use SSL in Console" in the Encryption tab on the Directory Server console. This seems a strange solution to the problem. Why would disabing anonymous access break console access and why would enabling "Use SSL in Console" fix it?
When you first log in to the console, and you type in your ID, the directory server has no credentials, and has to perform an anonymous search for uid=youruid to find your BIND DN. This is the same as when you log in to the operating system - pam has to do a search like uid=youruserid as anonymous to find your BIND DN. Not sure why selecting Use SSL in Console would fix that.
You can use 389-console -D 9 -f console.log to get detailed logging.
I get another interesting error as well with the "Use SSL in Console" checkbox checked. Login to Management Console Open Directory Console Click on Configuration tab Click on Encryption tab
I get "An error has occured" Could not open file(null). File does not exist or filename is invalid.
After I click on OK, I can proceed to the Encryption tab. Is this a bug or me not configuring something. The error message is not very helpfull.
I think you have to install the CA cert in the admin server cert db before you can do Use SSL in Console.
Regards
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Rich Megginson wrote:
When you first log in to the console, and you type in your ID, the directory server has no credentials, and has to perform an anonymous search for uid=youruid to find your BIND DN. This is the same as when you log in to the operating system - pam has to do a search like uid=youruserid as anonymous to find your BIND DN. Not sure why selecting Use SSL in Console would fix that.
It does not /have/ to perform an anonymous bind, it can do a proxy bind. PAM supports this as well, just by providing it with a 'binddn' and 'bindpw' in /etc/ldap.conf.
The console should also support proxy authentication.
-Brandon
Brandon G wrote:
Rich Megginson wrote:
When you first log in to the console, and you type in your ID, the directory server has no credentials, and has to perform an anonymous search for uid=youruid to find your BIND DN. This is the same as when you log in to the operating system - pam has to do a search like uid=youruserid as anonymous to find your BIND DN. Not sure why selecting Use SSL in Console would fix that.
It does not /have/ to perform an anonymous bind, it can do a proxy bind. PAM supports this as well, just by providing it with a 'binddn' and 'bindpw' in /etc/ldap.conf.
The console should also support proxy authentication.
Please file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=389
-Brandon
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Brandon G wrote:
Rich Megginson wrote:
When you first log in to the console, and you type in your ID, the directory server has no credentials, and has to perform an anonymous search for uid=youruid to find your BIND DN. This is the same as when you log in to the operating system - pam has to do a search like uid=youruserid as anonymous to find your BIND DN. Not sure why selecting Use SSL in Console would fix that.
It does not /have/ to perform an anonymous bind, it can do a proxy bind. PAM supports this as well, just by providing it with a 'binddn' and 'bindpw' in /etc/ldap.conf.
The console should also support proxy authentication.
Please file a bug at https://bugzilla.redhat.com/enter_bug.cgi?product=389
https://bugzilla.redhat.com/show_bug.cgi?id=627906
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
From: 389-users-bounces@lists.fedoraproject.org [389-users-bounces@lists.fedoraproject.org] on behalf of Gerrard Geldenhuis [Gerrard.Geldenhuis@betfair.com] Sent: 10 August 2010 16:00 To: 389-users@lists.fedoraproject.org Subject: [389-users] Console breaks when enabling no anoymous binding
Hi If I set nsslapd-allow-anonymous-access: off I am not able to login to the 389-console. I can remedy this by checking the checkbox "Use SSL in Console" in the Encryption tab on the Directory Server console. >This seems a strange solution to the problem. Why would disabing anonymous access break console access and why would enabling "Use SSL in Console" fix it?
I get another interesting error as well with the "Use SSL in Console" checkbox checked. Login to Management Console Open Directory Console Click on Configuration tab Click on Encryption tab
I get "An error has occured" Could not open file(null). File does not exist or filename is invalid.
After I click on OK, I can proceed to the Encryption tab. Is this a bug or me not configuring something. The error message is not very helpful.
I found the cause of the problem for the "An error has occurred". When you first click on Manage Certificates in the Admin Server console it prompts you for a password and I believe create the cert store in /etc/dirsrv/admin-serv/ I then added the same CA that I used in /etc/dirsrv/slapd-testmasterserver/ cert db. However if you then again remove this CA you get the error has mentioned message as mentioned above. This is probably not strictly spoken a bug but it would be really "nice" if the error message could tell you that the cert database for the admin console is empty. I am not sure why it what the interdependence is but from my 10 000 feet view it seems not necessary. If there is any agreement I will file this as an enhancement request on bugzilla.
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
Gerrard Geldenhuis wrote:
From: 389-users-bounces@lists.fedoraproject.org [389-users-bounces@lists.fedoraproject.org] on behalf of Gerrard Geldenhuis [Gerrard.Geldenhuis@betfair.com] Sent: 10 August 2010 16:00 To: 389-users@lists.fedoraproject.org Subject: [389-users] Console breaks when enabling no anoymous binding
Hi If I set nsslapd-allow-anonymous-access: off I am not able to login to the 389-console. I can remedy this by checking the checkbox "Use SSL in Console" in the Encryption tab on the Directory Server console. >This seems a strange solution to the problem. Why would disabing anonymous access break console access and why would enabling "Use SSL in Console" fix it?
I get another interesting error as well with the "Use SSL in Console" checkbox checked. Login to Management Console Open Directory Console Click on Configuration tab Click on Encryption tab
I get "An error has occured" Could not open file(null). File does not exist or filename is invalid.
After I click on OK, I can proceed to the Encryption tab. Is this a bug or me not configuring something. The error message is not very helpful.
I found the cause of the problem for the "An error has occurred". When you first click on Manage Certificates in the Admin Server console it prompts you for a password and I believe create the cert store in /etc/dirsrv/admin-serv/ I then added the same CA that I used in /etc/dirsrv/slapd-testmasterserver/ cert db. However if you then again remove this CA you get the error has mentioned message as mentioned above. This is probably not strictly spoken a bug but it would be really "nice" if the error message could tell you that the cert database for the admin console is empty. I am not sure why it what the interdependence is but from my 10 000 feet view it seems not necessary.
What's not necessary? Note that the admin server and directory server have separate cert databases. Also note that the NSS crypto team is working towards a unified system-wide cert db.
If there is any agreement I will file this as an enhancement request on bugzilla.
Regards
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
I found the cause of the problem for the "An error has occurred". When you first click on Manage Certificates in the Admin Server console it prompts you for a password and I believe create the cert store in /etc/dirsrv/admin->serv/ I then added the same CA that I used in /etc/dirsrv/slapd-testmasterserver/ cert db. However if you then again remove this CA you get the error has mentioned >message as mentioned above. This is probably not strictly spoken a bug but it would be really "nice" if the error message could tell you that the cert database for >the admin console is empty. I am not sure why it what the interdependence is but from my 10 000 feet view it seems not necessary.
What's not necessary? Note that the admin server and directory server have separate cert databases. Also note that the NSS crypto team is working towards a unified system-wide cert db.
That could have been more clear, I meant that a lack of certs in the Admin Server db should not cause an error when trying to access cert information in the directory server db. But as I said that is from 10 000 feet viewpoint.
A system-wide cert db would be really cool. Out of interest, would that also unify /etc/openldap/cacerts?
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
Gerrard Geldenhuis wrote:
I found the cause of the problem for the "An error has occurred". When you first click on Manage Certificates in the Admin Server console it prompts you for a password and I believe create the cert store in /etc/dirsrv/admin->serv/ I then added the same CA that I used in /etc/dirsrv/slapd-testmasterserver/ cert db. However if you then again remove this CA you get the error has mentioned >message as mentioned above. This is probably not strictly spoken a bug but it would be really "nice" if the error message could tell you that the cert database for >the admin console is empty. I am not sure why it what the interdependence is but from my 10 000 feet view it seems not necessary.
What's not necessary? Note that the admin server and directory server have separate cert databases. Also note that the NSS crypto team is working towards a unified system-wide cert db.
That could have been more clear, I meant that a lack of certs in the Admin Server db should not cause an error when trying to access cert information in the directory server db. But as I said that is from 10 000 feet viewpoint.
The SSL client must have a CA cert. In this case, the SSL client is the Admin Server, and the SSL server is the configuration directory server (the directory server that holds o=NetscapeRoot). When the "Use SSL in Console" is selected, the console and admin server will use SSL to contact the configuration DS.
A system-wide cert db would be really cool. Out of interest, would that also unify /etc/openldap/cacerts?
Not sure, but I would assume it would include those as well.
Regards
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
What's not necessary? Note that the admin server and directory server have separate cert databases. Also note that the NSS crypto team is working towards a unified system-wide cert db.
That could have been more clear, I meant that a lack of certs in the Admin Server db should not cause an error when trying to access cert information in the >directory server db. But as I said that is from 10 000 feet viewpoint.
The SSL client must have a CA cert. In this case, the SSL client is the Admin Server, and the SSL server is the configuration directory server (the directory server that holds o=NetscapeRoot). When the "Use SSL in Console" is selected, the console and admin server will use SSL to contact the configuration DS.
Just to clarify this.
Do I only need the CA cert in the /etc/dirsrv/admin-serv/ cert database or do I need the server CA in there as well. If so I could for all intents and purposes copy /etc/dirsrv/slapd-testserver/*.db to /etc/dirsrv/admin-serv/ ?
Also I am not sure where the certdb password for /etc/dirsrv/admin-serv/ is stored?
Regards
________________________________________________________________________ In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
________________________________________________________________________
Gerrard Geldenhuis wrote:
What's not necessary? Note that the admin server and directory server have separate cert databases. Also note that the NSS crypto team is working towards a unified system-wide cert db.
That could have been more clear, I meant that a lack of certs in the Admin Server db should not cause an error when trying to access cert information in the >directory server db. But as I said that is from 10 000 feet viewpoint.
The SSL client must have a CA cert. In this case, the SSL client is the Admin Server, and the SSL server is the configuration directory server (the directory server that holds o=NetscapeRoot). When the "Use SSL in Console" is selected, the console and admin server will use SSL to contact the configuration DS.
Just to clarify this.
Do I only need the CA cert in the /etc/dirsrv/admin-serv/ cert database
You only need the CA cert in there for the client side of SSL.
or do I need the server CA in there as well.
I think you mean server cert. No, you do not need the server cert for SSL client. However, if you want the admin server to be an SSL server, you will need the server cert.
If so I could for all intents and purposes copy /etc/dirsrv/slapd-testserver/*.db to /etc/dirsrv/admin-serv/ ?
Yes.
Also I am not sure where the certdb password for /etc/dirsrv/admin-serv/ is stored?
You don't need the password for SSL client.
Regards
In order to protect our email recipients, Betfair Group use SkyScan from MessageLabs to scan all Incoming and Outgoing mail for viruses.
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
389-users@lists.fedoraproject.org