As DominoMeter processes each server document, per our last discussion it will start to integrate whether the web site document or Internet site document is in use.
DominoMeter can then pull in and summarize as it does with the Program documents the information in either web site documents (old) or Internet site documents (new).
Obviously most customers should be on Internet site documents in a perfect world, but the reality is I think we have many left on the old web site document method.
Making matters more complex, we have some customers who have enabled IDentity Provider (IDP) and in a couple of cases, some totally other authentication system (PortalGuard) that I guess uses SAML?
It's very confusing to me all the different ways in which Domino can be configured right now for basic authentication, single server authentication, multi server authentication, IDP, SAML, and probably even custom DSAPI filters (which maybe PortalGuard on Windows uses but on Linux they use SAML)... I can't remember.
Hopefully Doug can chime in on this.
Anyway, we need to get a handle on this. We need a view showing basically checkboxes of which items are actually in use, and ultimately be able to resolve the question of:
1) what domain name and public/private IP addresses (both sides of NAT) is the HTTP server going to actually respond to
2) what is the user going to 'see' when the try to authenticate. The basic Domino login page? Or a custom login page? If a custom login page, where is it defined?
3) what is the server going to 'do' when actually presented with authentication details for validation? look only at names.nsf? look at da.nsf as well? check an IDP? check a SAML thing? check a custom DSAPI filter?
This will help us determine why Jedi does not go into Running mode, why SystemHealth can't authenticate to get the information it needs, and what level of security the user generally is experiencing from a login perspective. It looks pretty bad these days to have big customers on basic authentication, for example. I hope we don't have any like that, but I honestly have no idea without a manual check right now. DominoMeter and the above logic could help us answer that question.
I think you may have already added this - but if not - we also need to start analyzing the ciphers and key exchanges that are accepted.
This winds also into the topic we touched on recently of which SSL keys are actually defined on which Domino servers, so that we stop missing them. I would very much like to find a way to ensure the correct key is distributed to the correct Domino servers; possibly this could be done by using a CRC64 hash (which is native Java) of the keys referenced by the server document, Internet site document, and/or web configuration document (I forget if they even support direct SSL keys).... and then as we build out a central database of actual SSL keys for which customers and when they expire, we can compare the central database to Domino.
SSL key tracking, distribution, and renewal is a HUGE problem for us that is very labor intensive and error prone right now, which is another major thing we need to try to fix.
Hi Dmytro,
As DominoMeter processes each server document, per our last discussion it will start to integrate whether the web site document or Internet site document is in use.
DominoMeter can then pull in and summarize as it does with the Program documents the information in either web site documents (old) or Internet site documents (new).
Obviously most customers should be on Internet site documents in a perfect world, but the reality is I think we have many left on the old web site document method.
Making matters more complex, we have some customers who have enabled IDentity Provider (IDP) and in a couple of cases, some totally other authentication system (PortalGuard) that I guess uses SAML?
It's very confusing to me all the different ways in which Domino can be configured right now for basic authentication, single server authentication, multi server authentication, IDP, SAML, and probably even custom DSAPI filters (which maybe PortalGuard on Windows uses but on Linux they use SAML)... I can't remember.
Hopefully Doug can chime in on this.
Anyway, we need to get a handle on this. We need a view showing basically checkboxes of which items are actually in use, and ultimately be able to resolve the question of:
1) what domain name and public/private IP addresses (both sides of NAT) is the HTTP server going to actually respond to
2) what is the user going to 'see' when the try to authenticate. The basic Domino login page? Or a custom login page? If a custom login page, where is it defined?
3) what is the server going to 'do' when actually presented with authentication details for validation? look only at names.nsf? look at da.nsf as well? check an IDP? check a SAML thing? check a custom DSAPI filter?
This will help us determine why Jedi does not go into Running mode, why SystemHealth can't authenticate to get the information it needs, and what level of security the user generally is experiencing from a login perspective. It looks pretty bad these days to have big customers on basic authentication, for example. I hope we don't have any like that, but I honestly have no idea without a manual check right now. DominoMeter and the above logic could help us answer that question.
I think you may have already added this - but if not - we also need to start analyzing the ciphers and key exchanges that are accepted.
This winds also into the topic we touched on recently of which SSL keys are actually defined on which Domino servers, so that we stop missing them. I would very much like to find a way to ensure the correct key is distributed to the correct Domino servers; possibly this could be done by using a CRC64 hash (which is native Java) of the keys referenced by the server document, Internet site document, and/or web configuration document (I forget if they even support direct SSL keys).... and then as we build out a central database of actual SSL keys for which customers and when they expire, we can compare the central database to Domino.
SSL key tracking, distribution, and renewal is a HUGE problem for us that is very labor intensive and error prone right now, which is another major thing we need to try to fix.