Quickstart Guide: Setting up Active Directory Single Sign-On (SSO) on a SLES11 , SLES12, or SLES15 Linux Post Office for GroupWise 14.2.2 or 18.1, in a non-clustered environment

  • 7018598
  • 07-Feb-2017
  • 19-Sep-2019

Environment

Novell GroupWise 2014 R2 Support Pack 1
Novell GroupWise 2014 R2 Support Pack 2
GroupWise 18

Situation

I want more step by step directions on how to setup Active Directory Single Sign-On with a Linux GroupWise Post Office on SLES11, SLES12, or SLES15, than what is currently in the GroupWise documentation.

Resolution

Assumptions :

a.   It is assumed you are working with a Microsoft Windows 2012 R2 Server Domain Controller, hereafter called “Windows Domain Controller”


b.   For the example purposes of this document, it is assumed that the GroupWise Linux Post Office Server fully qualified hostname is “bperez140.lab.novell.com” and that the “Windows Domain Controller” fully qualified hostname is “bperez76.lab.novell.com”.  Substitute your hostnames as appropriate.

  

In this example the Active Directory “user” and the GroupWise UserID are both “aduser1” that we will work with.  I assume your SLES11, SLES12, or SLES15 server is up to date on patches.


c.   So in this example on the “Windows Domain Controller”, in the DNS application, under "Forward Lookup Zones", you would have defined a DNS zone called "LAB.NOVELL.COM" ( but substitute your DNS zone name ) and under this zone you would create a DNS A record that would have a "Host" name of "bperez140" and it has a "Fully qualified domain name (FQDN) of "bperez140.lab.novell.com" along with the ip address that resolves to bperez140.lab.novell.com.  Make the proper name substitutions as you need.


d.  It is assumed that you have created an Ldap Directory and Ldap Server in the GroupWise Web Admin Console under SYSTEM, "Ldap Servers" by following the steps listed in Section 6.1 , steps 1 thru 6 of this URL :  

    GroupWise 14.2.2 :

  https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/data/b199manl.html

  and this section 6.2.1, steps 1 thru 6 of this URL :

      https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/data/b199mao7.html 

 

    GroupWise 18 :  Same steps as above: :

https://www.novell.com/documentation/groupwise18/gw18_guide_admin/data/b199manl.html

 

https://www.novell.com/documentation/groupwise18/gw18_guide_admin/data/b199mao7.html

 

e.  It is assumed that you have imported the Active Directory users into GroupWise, that will be using the Single Sign-On (SSO) feature.  So these users are associated with the Active Directory server listed in the Ldap Servers.


f.  Lastly it is assumed on your “Windows Domain Controller” box, in “Active Directory Users and Computers”, View, that you have "checked", “Advanced Features”.

 

NOTE:

Since you will be changing the Security setting for the Post Office Agent, consider doing this on a Friday night after hours to minimize user impact.  Or you could certainly test this procedure on a GroupWise Test server, that is not production, until you are comfortable that it will work as you expect.

 

NOTE:

Have a full complete backup of the GroupWise System before performing these steps, in case there are any Issues.  However these steps worked correctly for me on my SLES11 GroupWise Server and Windows 7 workstation with the GroupWise 2014 R2 Windows client.

 

NOTE:  For any additional GroupWise servers that you want to have Single Sign-On functionality with Active Directory then you would just repeat the steps in this Technical Document for each additional Linux server where there is a GroupWise Post Office.

 

Steps to Follow : 

For Linux Post Office Server you will have to "Join" the “Windows Domain Controller” and make the below changes NOW :

1.      You need to know the current fully qualified hostname for the Linux GroupWise Post Office Server, let"s say it is:

     a.     bperez140.lab.novell.com

 

2.      You need to know the current fully qualified hostname for your Active Directory Domain Server, let"s say it is:

     a.     bperez76.lab.novell.com

 

3.      Then the Linux Post Office Server will likely need a change to it's listed "Name Server" in YAST, in this example: ( The Windows Domain Controller )

     a.     I.P address of the Windows Domain Controller

     b.     To make this "Name Server" change go to Yast, Network Devices, Network Settings, 

        and in the Hostname/DNS tab, the "Hostname" would have to be "bperez140" , no 

quotes, and the "Domain Name" would have to be :  "lab.novell.com", no quotes.  But substitute your host and domain name as appropriate in your situation, change it NOW.


     c.     AND in this same tab, the "Name Server 1" would have to have the ip 

address of your “Windows Domain Controller”.  Do not have any values for

"Name Server 2" and "Name Server 3" .  The "Domain Search" list box to the 

right would have to show – "lab.novell.com", no quotes.  But substitute your domain name as appropriate in your situation, change it NOW.


     d.      The Routing tab, the "Default Gateway", would of course have to be filled out correctly for your network environment.  CLICK OK and exist YAST.


     e.     The result would be that when you go to a terminal as "root" on the Post Office 

Server, you should at least be able to PING internal and external ip addresses or hostnames to make sure you have proper ip connectivity.


4.     Go to the below GroupWise 14.2.2 documentation URL for "Configuring Single Sign-On with Active Directory" (54.2):

    a.     https://www.novell.com/documentation/groupwise2014r2/gw2014_guide_admin/data/b1f0s9uy.html 

 

    OR for GroupWise 18 Documentation:

https://www.novell.com/documentation/groupwise18/gw18_guide_admin/data/b1f0s9uy.html

 

 

    b.     With the above GroupWise documentation URL, under the section "Configuring Single Sign-On with Active Directory" (54.2), we will go over the listed first 4 bullet points in order:

 

    c.     For the 1st bullet point, make sure both the POA Linux Server and the User Windows Workstation are joined to the same “Windows Domain Controller”:

 

        i.     On the Linux box where the Post Office is located, Click Computer, Yast, Network Services, Windows Domain Membership, on Membership "Domain or Workgroup", type domain name NOW for your “Windows Domain Controller”, in this example, but substitute yours :    

               "lab.novell.com"

 

        ii.     Click the Expert Settings button, for the Kerberos Method select "system keytab", then Click OK. 


        iii.     Click the "NTP Configuration" button, to ensure time synchronization between the Linux Post Office Server and the “Windows Domain Controller”, as needed, set the Time server by clicking ADD, type your ntp time server hostname, Click Test.  Irt should respond with “Server is reachable and responds properly”.  Click OK, then OK again.  And Click OK once more.  Click OK again. 


You should see a dialog that pops up that “This host is not a member of the domain LAB”, “Join the domain LAB ?”, Click Yes.

In the resulting dialog put in the Windows domain controller “administrator” username and password and CLICK OK.


        iv.     You should see a resulting dialog that says “Domain LAB joined successfully.” Click OK. 


         v.     Now to Join the User Workstation, Go to the Windows PC, It is assumed you are not yet joined.  On either Windows 7 or Windows 8.1, or Windows 10: 


               1.     Right click the Network Icon in the Windows Tray, select "Open Network and Sharing Center", select "Change Adapter Settings", Right Click the appropriate Network Card, Highlight "Internet Protocol Version 4 (TCP/IPv4)" and Click Properties.

 

               2.     For the "User the following DNS Server addresses:", for the "Preferred DNS server", type the IP address of your “Windows Domain Controller”. Click OK then CLOSE.


               3.     Now to actually Join to the “Windows Domain Controller”, go to :   

                    a.     Windows 7 workstation, Click Start, Right Click "Computer", Properties, Advanced System Settings, Computer Name tab, to Change to a Domain, click the Change button. 


                    b.     For the Member Of : Domain , list box , type the fully qualified hostname of the “Windows Domain Controller” (my example, “lab.novell.com”).  Click OK.  Supply the appropriate Active Directory credentials ( I use the “Windows Domain Controller” “administrator” user in my test system) , Click OK, then you should successfully Join and get a confirmation on this.  Click OK.   Click OK again to RESTART your computer as required by Windows.  I assume you will Click RESTART NOW.


                   c.     When the Workstation reboots, you will come to a Windows Logon dialog, type for the Username: 

                            i.     The name of your <Windows Domain Controller Netbios name>\A.D. UserName, example, in this example case for me it is :

  "LAB\aduser1"                                                                                                                                                                                                      

                          ii.     Type the password for this Active Directory User and LOGIN


                  d.     To confirm your credentials that the GroupWise Single Sign-On depends on, to go a DOS Window (cmd) and type "whoami", it should respond with, in this example: 

                           lab\aduser1

 

                  e.     Close the DOS Window. 


                  f.     Now for the 2nd bullet point listed in the above Documentation URL: 

"Make sure the POA object has the DNS fully qualified domain name instead of the IP address :

 

In the GroupWise Admin Console > Post Office Agents > select the POA 

> Agent Settings > TCP/IP Address Field."  :

In this example, the value should already be:  "bperez140.lab.novell.com".  Make this change as needed NOW if necessary.  Remember no I.P. Address, just the hostname. 


                  g.     For the 3rd bullet point of the Documentation URL : "Enable LDAP authentication in the GroupWise Admin Console > Post Offices > select the PO > Security tab.  Make sure your “Windows Domain Controller” Ldap Server name is selected here.   If needed refer to ‘Assumptions” point “d” at the top of this document.


                  h.      For the 4th bullet point of the Documentation URL: "Select Network authentication (eDirectory or Active Directory)” in the Admin Console > Post Office Agents > select the POA > Client Options > Security tab.  Do this change now.  Remember to Click on SAVE.

  

 Now it"s time to move on in the Documentation to Section 54.2.2, "Linux POA", there are 7 bullet points :

 

5.     For the 1st of 7 bullet points, "Make sure that all krb5 rpms are installed on the server".  This means that you should check in YAST, Software Management, search, type "krb5", no quotes and click the SEARCH button.

 

a.              You should have "checked" "krb5", "krb-32bit", AND "krb5-client", if you don't have all of these check off the missing one and CLICK the ACCEPT button in the lower right of the dialog.  Exit YAST.

 

b.             You can also check what krb5 libraries you have installed by going to the linux terminal as “root” and issuing the command:

 

a.      rpm -qa | grep krb5


b.     you should see:  krb5-client-<versionNumber>, krb5-<versionNumber>, and krb5-32bit-<versionNumber>

 

6.     2nd bullet point, “Make sure that the Linux server points to the AD Server as it"s DNS Server” :  

 

    We already did this.  Next step.


7.     3rd bullet point, "Join the Linux POA server to the Windows Domain by ……” :              

              We already did this.  Next step.


8.     4th bullet point, “Configure Kerberos by editing …..” refer to this example file instead to check and verify what is configured in the file, modify NOW as appropriate for your environment, note the lines that are offset, they are “tabbed” not spaces, note the case of letters :  

          vi /etc/krb5.conf :

[libdefaults]

        default_realm = LAB.NOVELL.COM

        clockskew = 300 

[realms]

LAB.NOVELL.COM = {

        kdc = lab.novell.com

        default_domain = lab.novell.com

        admin_server = lab.novell.com

}

 

[logging]

        kdc = FILE:/var/log/krb5/krb5kdc.log

        admin_server = FILE:/var/log/krb5/kadmind.log

        default = SYSLOG:NOTICE:DAEMON

 

[domain_realm]

        .lab.novell.com = LAB.NOVELL.COM

        lab.novell.com = LAB.NOVELL.COM

 

9.     5th bullet point, at a terminal on the Linux Post Office Server, as "root", issue this command NOW :  NOT the command in the documentation, unless it is the same :

 

a.        net -U administrator@<Windows Domain Controller> ads keytab add groupwise

i.    example, like:  net -U adminstrator@lab.novell.com ads keytab add groupwise

 

        b.     Type the password for the “Windows Domain Controller” "administrator" user 

        

c.     At the terminal on the GroupWise Linux server, cd to /etc, then issue the command "klist -k", no quotes, you should see among other content, as in this example, yours will be different :  5 or so lines that show :              

              i.     <a number> groupwise/bperez140.lab.novell.com@LAB.NOVELL.COM 

       

      ii.     You MUST see this fully qualified domain name, yours will be different, that is to the left of the "@" character, "bperez140.lab.novell.com" 


10.   6th bullet point, Make sure that the /etc/krb5.keytab file is readable by the user that is running the GroupWise POA on the server.  

So if you run the GroupWise agents as "root", or another 

user, then that user must have ownership of this file.  

So when you go to the /etc/ directory on the Post Office Linux Server and issue the command, as "root",  "ls -l krb5.keytab"  , no quotes.  

You will see the owner of the file, root is the owner here :

        a.     -rw- - - - - - -  1 root  root 2027 Jan 22 15:16 krb5.keytab 

    

        b.     And to compare who is running the POA process, issue the command at the 

terminal : "ps -eaf | grep gwpoa", no quotes, the owner is in the first left most column.  


If it says "root" then there is a match and the ownership of this file is good.  If there is not a match, then you MUST change the ownership of the krb5.keytab file NOW with this command , to match the user who is running the POA agent, at the /etc/ directory :   

   "chown <userNameWhoRunsPOA>:users ./krb5.keytab", no quotes. 


        c.     I assume that If this is the "root" user, then "root" is part of the "root" group.  If the user is not the "root" user then, let"s say the user is called "gwuser", I assume that "gwuser" is part of the Linux group called "users".  

Then you must assign the appropriate user and group file permissions.  As appropriate do this NOW :  either : 

             i.     cd to the /etc/ directory, and issue the below commands NOW : 


            ii.     chmod ug=rwx ./krb5.keytab


11.   ( Optional ) 7th and final bullet point, "Create a GroupWise Name Server in DNS".  If you do not do this, users need to know the IP address and port number to connect to the POA.  Consider below point 11a instead.

          a.     It is recommended you follow this technical document to accomplish this by creating a Microsoft Service Connection Point (SCP), which has similar functionality to ngwnameserver :   


https://support.microfocus.com/kb/doc.php?id=7023422 .  DO THIS STEP NOW.

 

12.  Note:  In this example situation, when you start the GroupWise Windows Client the first time after enabling Single Sign-On, you should see the "Micro Focus GroupWise Startup" dialog, and in this dialog you “should” see "Connecting to Post Office at : bperez140.lab.novell.com: 1677".  Substitute your hostname for GroupWise.  If you do not see the correct hostname or you see an ip address, then just click CANCEL and correct the "Address" list box to show your GroupWise hostname, fill out the rest of the information needed in this dialog and CLICK OK.  Now when you successfully login, it will remember your credentials and the next time you attempt to login to GroupWise you should not be prompted for your password.


Closing Comment:

If you follow this Document and if you have a problem where you are still prompted for a password when attempting to login to the GroupWise Windows client and if you are on SLES11, it could be that you may have an older version of the linux Kerberos "krb5" files,  you can review this TID on how to check on and correct this issue :

https://support.microfocus.com/kb/doc.php?id=7021409

 

Other things to check if you still are prompted for a password:

1.     Be sure to verify that the “root” user owns the “/etc/krb5.keytab” file on the GroupWise Linux Post Office Server and has RWX permissions, and also the group “root”.  One command that will set this as described is :


a.      Chmod ug=rwx ./krb5.keytab

 

2.     Verify on the “Windows Domain Controller”, in the application “Active Directory Users and Computers”, under the Active Directory Organization called “Computers” has an object called the name of your GroupWise Linux Post Office Server name.  Under this object, go under Properties, Attribute editor tab, you should have an attribute called “servicePrincipalName”.  If you edit this attribute, you should see among other things, “groupwise/bperez140.lab.novell.com” .  No quotes, and substitute your GroupWise Post Office Server hostname.

 

3.     From the perspective of the user, in Windows, in the GroupWise Windows 14.2.2 or 18.1 client, click on Tools, Options, Security, Password tab, at the bottom you should have a checkmark in the checkbox “No password required with eDirectory”.  If you do not, Single Sign-On will not work.  If it is not "checked", just type in your password in the “Old password” listbox, then the checkbox will not be greyed out, so you can check it.  Then click APPLY and OK.  Then exit the GroupWise Windows client and re-login.

 

4.     Also on the user Windows workstation, go to the Dos Window ( cmd ) , and cd to : c:\windows\system32\ , then type the command “klist” no quotes, you should see among other things a reference to the GroupWise Kerberos ticket, for me is shows :

Client:  aduser1 @ LAB.NOVELL.COM

Server:  groupwise/bperez140.lab.novell.com @ LAB.NOVELL.COM 

KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96

Ticket Flags 0x40a10000 -> forwardable pre_authent name_canonicalize

Start Time: 3/30/2019 20:07:36 (local)

End Time:   3/31/2019 5:11:26 (local)

Renew Time: 4/6/2019 19:11:26 (local)

Session Key Type: AES-256-CTS-HMAC-SHA1-96

5. If Single Sign-On (SSO) is still not working, (you are being prompted for a password, then do the below, after hours, so not to potentially affect Post Office users, you will be toggling some settings under the Post Office and POA objects :

a. In the GroupWise Web Admin Console, under the Post Office object, Security tab, it is assumed you have “LDAP Authentication” turned on and that the “Selected LDAP Servers” has a list of at least 1 Ldap server. Do this NOW, highlight the LDAP server that is used with this Post Office’s Single Sign-On process and CLICK the right arrow to move it to the “Available LDAP Servers” list. CLICK SAVE. Then CLOSE. Now go back to this same setting and put the LDAP server back in the “Selected LDAP Servers” list and CLICK OK.


b. In this same area CLICK the the “Client Options” button at the top, Security tab, and it is assumed you currently have the checkbox checked “Network authentication (eDirectory or Active Directory). Remove the checkmark on this setting. Click OK. Now go back to this same setting and CLICK the checkbox “Network authentication (eDirectory or Active Directory)” AND LOCK IT, by clicking on the LOCK to the right. CLICK OK. Click SAVE at the bottom left, then CLOSE.


c. Restart the affected POA at the GroupWise linux server terminal as “root”, issue : rcgrpwise status, you will see among other things : Assume your Post Office is called “provo” and your domain is called “utah” :

Checking status [provo.utah] running”

So issue the command : “rcgrpwise restart provo.utah”, no quotes.

Hopefully now Single Sign-On is now working at your Windows 7, 8 or 10 workstation that is configured as described in this document.

 

 

Feedback service temporarily unavailable. For content questions or problems, please contact Support.