Windows SSO for Web Apps
March 24 2010
Did you know you can do Windows SSO for Web clients in Domino 8.5? Did you know you could do this without "massive" changes to your Domino environment?
That's right! You can setup your Domino servers such that your Domino server can honor Microsoft Windows users' Active Directory logon credentials so that users who are logged onto the AD domain can open Domino applications without being prompted for a password! This may be a HUGE leap forward for many of you and make tons of your customers happy! This *could* mean that your end-users who only access web applications or iNotes web mail would NOT have to have a separate Notes/Domino login from their Windows login.
Here's essentially how it works...
First - you setup SSO for your Domino servers much like you normally would - setting up the multi-server session-based authentication (single sign-on) in the SSO Configuration documents (or Web Sites). Then, you setup the Windows service for the Domino server by having your AD administrator use the setspn utility to assign at least one service principal name (SPN) for that server to an AD account. That tells the Windows Kerberos Distribution Center (KDC) that a Kerberos service ticket can be issued to Domino.
Once Kerberos tickets can be issued to the Domino server, you then will setup user name mapping to enable a Domino server to reconcile users names found in both AD and the Domino Directory. This achieves three things - first, it makes it so that when Domino finds a user's LDAP name in AD and/or the Domino Directory, it enables the server to verify that the two names actually belong to a single user. Second, name mapping may be needed to determine a user's Notes distinguished name if the name passed to it was only an AD name. And, finally, name mapping specifies which Directory to use when Windows SSO is not available.
So - once all that is set up, you setup the web browsers on the clients to authenticate to Domino using Single Sign-On and voila! (well, sort of!!) ;-)
Now, there of course, are some caveats. First - and maybe most importantly, the end-user must actually log into the workstation and the AD domain. Additionally, the Domino server itself must be a part of the Windows AD domain - which means, yes, it must be running on a Windows server itself! In addition, the computer your end users are logging into must be able to authenticate into the AD domain and have network access to the AD server.
There are a few other requirements as well, and of course some other steps to make it happen. But, there is excellent documentation available in the Info Center and the administration help, so take a look here and get your clients setup for Windows SSO today!
That's right! You can setup your Domino servers such that your Domino server can honor Microsoft Windows users' Active Directory logon credentials so that users who are logged onto the AD domain can open Domino applications without being prompted for a password! This may be a HUGE leap forward for many of you and make tons of your customers happy! This *could* mean that your end-users who only access web applications or iNotes web mail would NOT have to have a separate Notes/Domino login from their Windows login.
Here's essentially how it works...
First - you setup SSO for your Domino servers much like you normally would - setting up the multi-server session-based authentication (single sign-on) in the SSO Configuration documents (or Web Sites). Then, you setup the Windows service for the Domino server by having your AD administrator use the setspn utility to assign at least one service principal name (SPN) for that server to an AD account. That tells the Windows Kerberos Distribution Center (KDC) that a Kerberos service ticket can be issued to Domino.
Once Kerberos tickets can be issued to the Domino server, you then will setup user name mapping to enable a Domino server to reconcile users names found in both AD and the Domino Directory. This achieves three things - first, it makes it so that when Domino finds a user's LDAP name in AD and/or the Domino Directory, it enables the server to verify that the two names actually belong to a single user. Second, name mapping may be needed to determine a user's Notes distinguished name if the name passed to it was only an AD name. And, finally, name mapping specifies which Directory to use when Windows SSO is not available.
So - once all that is set up, you setup the web browsers on the clients to authenticate to Domino using Single Sign-On and voila! (well, sort of!!) ;-)
Now, there of course, are some caveats. First - and maybe most importantly, the end-user must actually log into the workstation and the AD domain. Additionally, the Domino server itself must be a part of the Windows AD domain - which means, yes, it must be running on a Windows server itself! In addition, the computer your end users are logging into must be able to authenticate into the AD domain and have network access to the AD server.
There are a few other requirements as well, and of course some other steps to make it happen. But, there is excellent documentation available in the Info Center and the administration help, so take a look here and get your clients setup for Windows SSO today!
1) iconus wrote:
There is a more simple alternative:
{ Link }