LDAP channel binding changes coming (from Microsoft)

I need a solution

Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in mid-January 2020.”

If we use a System configuration task to bind to AD, is it doing the LDAP bind over SSL? 

Can anyone clarify if these new security measures on domain controllers (enforced with new win update) will break our binding during imaging process (via system config)?  What about technician access to the console?


I asked support for clarification, will report back if I get it.



7002943: How to configure GroupWise Clients to send and receive Encrypted and Signed E-Mails using eDirectory User Certificates

Prior to implement the solution have a look into the Notes: section

1. Create User Certificates

By default, only a user having “Admin” privileges can create User Certificates for users in an eDirectory Tree. So perform following steps as “Admin”.

1.1 Login as Admin using Novell Client from the administration workstation

1.2 Launch ConsoleOne, preferably one from a NetWare server with latest Support Pack (Sys:publicmgmtConsoleOne1.2binConsoleOne.exe)

1.3 Create couple of test user in the desired eDirectory container (Create “Michael Owen” and “John Terry”)

1.4 Create a GroupWise Mailbox for both users and set a GroupWise password for both of them (Use “novell” as password)

1.5 Take properties of the user object “Michael” in NDS View and select Security|Certificates page

1.6 Click on the button Create and create the User Certificate with following parameters as you proceed with the wizard

  • Certificate name: First Name of the User
  • Creation Method: Custom
  • Certificate Authority: Organizational Certificate Authority
  • Key Size: 2048 Bits
  • Key Type: Custom (Once “Custom” is selected enable all Check boxes which get highlighted)
  • E-Mail Address: Specify the E-Mail Address of the user (This field will be automatically filled for a user with mailbox)

1.7 Select the Certificate, click on “Validate” and make sure that Certificate is “Valid”

1.8 Repeat steps 1.5 to 1.7 and create a User certificate for John.

2. Export User Certificates

Even though a user with “Admin” privileges can create User Certificates for regular users, only the corresponding user can export the Certificate with Private Key. So login as test users using iManager from workstations and export User Certificate with Private Key as follows.

2.1 Launch iManager and login as Michael

2.2 Expand the Role “Directory Administration” and select the Task “Modify Object”

2.3 Browse and select the user Object “Michael” and click on “OK”

2.4 Click on “Certificates” tab, select the certificate and export the certificate along with Private Key

2.5 Save the file as “Michael.pfx” into the workstation

2.6 Repeat steps 2.1 to 2.5 by logging in as John and export the certificate for John as “John.pfx

3. Setup an eDirectory LDAP server

Select an eDirectory server with Master or Read/Write replicas of all main partition as an LDAP Server. It’s recommended that the LDAP server should have a replica of Tree [Root] partition for best performance. GroupWise Client by default use query the LDAP server on port 389 (Default non-secure LDAP port). Make sure that LDAP is listening on port 389 as follows

3.1 From Administration workstation, login as Admin using Novell Client and launch ConsoleOne (Launch ConsoleOne from the server to have all necessary snap-ins for LDAP)

3.2 Browse to the server context of the desired LDAP server

3.3 Take properties of the LDAP Group – <Server_Name> Object for the desired LDAP server

3.4 On the General | LDAP Group General tab, disable the Check Box “Require TLS for Simple binds with password”, apply the change and close the properties page.

3.5 Open a server console and reload NLDAP as follows

A. On NetWare

unload nldap


B. On Linux

nldap -u

nldap -l

3.6 Ensure that LDAP is listening port 389 using Novell Import Convert Export (ICE) utility or other commonly used LDAP tool like LDAP Browser 2.8.2

4. Add the eDirectory LDAP Server in Novell Address Book of GroupWise Client

From here onwards use separate workstations for Michael and John. Wherever it is mentioned to login as John or Michael using Novell Client or GroupWise Client, use the workstation for the user. Using separate workstations helps to differentiate configuration needed for encryption and signing.

4.1 Login as Michael using Novell Client

4.2 Login as Michael using GroupWise Client

4.3 Click on Address Book | Novell LDAP Address Book | Directories

4.4 Click on Add and add an entry called “eDirectory” by providing details of the desired LDAP Server as follows,

  • Server Address: IP Address of the LDAP server
  • Port: 389 (Default non-secure LDAP port)
  • Server Requires log in: Leave unchecked

4.5 Select “eDirectory”, click on the button “Set as Default” and click on “Close”

4.6 Check you are able to query user “John” by typing John’s E-Mail Address in the field “E-Mail Address” and by clicking the button “Retrieve”

4.7 If successful, close the Address Book

Don’t define the LDAP server in the GroupWise Client on John’s workstation at this point.

5. Configure GroupWise Client to search eDirectory for encryption Certificate

GroupWise Client of the sender uses the Public Key of the recipientuser to encrypt the E-Mail. Configure the GroupWise Client of Michael(Sender) to search the eDirectory LDAP server for the Public Key of John as follows.

5.1 Login as Michael using GroupWise Client

5.2 Click on Tools | Options | Send | Security | Advanced Options

5.3 Enable the Check box “Search recipient encryption certificates in the default LDAP directory defined in LDAP Address Book”

5.4 Click on “OK” and close the “Options” Page

6. Install User Certificate with Private Key in GroupWise Client

Perform following steps as John (Not as Michael). Copy over the User Certificate for John to John’s workstation.

6.1 Copy the User Certificate for John, John.Pfx, to John’s workstation

6.2 Login as John using GroupWise Client

6.3 Click on Tools | Options | Certificates

6.4 Click on Import and install the User Certificate for John, ignoring the “Security Warning”

  • Certificate file to import: Point to John.Pfx
  • Enter password: The password specified while exported the certificate with Private Key
  • Security Warning: Ignore the message (Wizard throws out a Security Warning as the certificate is issued by Organizational Certificate Authority (CA) which is not trusted as VeriSign, a popular Public CA)

6.5 Select the Certificate and click on “Set as Default”

6.6 Click on “OK” and close the “Options” page.

Don’t import the user certificate for Michael into the GroupWise Client on Michael’s workstation at this point.

7. Test Encrypted E-Mail

GroupWise Client of Michael will be able to find out the Public Key for John using configurations done as per Steps 4 and 5.

7.1 Send Encrypted E-Mail

7.1.1 Login as Michael using GroupWise Client

7.1.2 Open a “New Mail” and select John using Address Book (Not LDAP Address Book)

7.1.3 On the “Mail To:” window click on the tab Send Options | Security and enable the Check box “Enable for recipients”

7.1.4 Type a few words / a sentence on the Message Body and /or attach a file and send the E-Mail

7.1.5 Switch to the folder “Sent Items” and make sure that you can differentiate the encrypted E-Mail using a “Lock” icon

7.2 Open and verify the Encrypted E-Mail

GroupWise Client of recipient uses the Private Key of the recipient to decrypt incoming encrypted E-Mails. John’s GroupWise Client will be able to open the encrypted E-Mail sentby Michael as the certificate with Private Key for John, is alreadyimported as per step 6.

7.2.1 Login as John using GroupWise Client

7.2.2 Open the encrypted E-Mail Michael sent and make sure that you are able to see contents of the E-Mail, sentence on the Message Body or attached file.

7.2.3 Close the encrypted E-Mail

Trying to send an encrypted reply E-Mail as John will fail as an entry for the eDirectory LDAP server is not yet added in to the Novell LDAP Address Book of John’s GroupWise Client. Similarly, Michael will not be able to view the message body contents or attached file of an encrypted E-Mail from John, until the user certificate with Private Key (Michael.Pfx) is imported into Michael’s GroupWise Client.

8.Test Signed E-Mail

GroupWise client uses the Private Key of the sender to send a Signed E-Mail. GroupWise client of the recipient searches the LDAP Server defined in the LDAP Address Book for the Public Key of the sender to “Validate” the Signature on the incoming Signed E-Mail. Based on configuration done so far, attempt to send Signed E-Mail as Michael will fail as the Private Key for Michael is not yet imported into his GroupWise Client. Try to send a Signed E-Mail as John as the Private Key for John is already imported into GroupWise Client. Proceed as follows.

8.1 Send a Signed E-Mail

8.1.1 Login as John using GroupWise Client

8.1.2 Open a “New Mail” and select Michael using Address Book (Not LDAP Address Book)

8.1.3 On the “Mail To:” window click on the tab Send Options | Security and enable the Check box “Sign Digitally”

8.1.4 Type a few words/sentence on the Message Body and/or attach a file and send the E-Mail

8.1.5 Switch to the folder “Send Items” and make sure that you can differentiate the Signed E-Mail

8.2 Open and Verify the Signed E-Mail

8.2.1 Login as Michael using GroupWise Client

8.2.2 Open the Signed E-Mail John sent and make sure that contents on the message body is visible.

8.2.3 Close the Signed E-Mail

Michael will not be able to send a Signed E-Mail to John as the User Certificate with Private Key for Michael is not yet imported into the GroupWise Client for Michael. Similarly, John will not be able to “Validate” the Signature on Signed E-Mails from Michael, until the eDirectory LDAP server is added to the Novell LDAP Address Book of John’s GroupWise Client.


7022780: Get the most out of Novell Open Enterprise Server 2015

  • Maximum Cached Sub-directories Per Volume: 1024000

    This is settable by executing “novcifs -k SDIRCACHE=1024000” as root.
  • Maximum Cached Files Per Subdirectory: 102400

    This is settable by executing “novcifs -k DIRCACHE=102400” as root.
  • Maximum Cached Files Per Volume: 2048000

    This is settable by executing “novcifs -k FILECACHE=2048000” as root.

If you however are experiencing inaccessible CIFS shares, CIFS stops listening or communicating, becomes unresponsive or the novell-cifs daemon hangs or other CIFS or novell-cifs daemon related issues, please check TID 7008956 “Troubleshooting and Debugging CIFS on Open Enterprise Server”.

In the lifespan of OES2015 a memory leak was addressed in the NMAS code used for and by the novell-cifsd.

The code on disk is part of the oes2015sp1-July-2017-Scheduled-Maintenance patch, or later.

More details on how to check and when required update the code in the eDirectory can be found in TID 7022690 “ndsd memory leak caused by novell-cifs nmas authentication method on OES2015.1”


As several services rely on the Novell Authentication Module for their authentication to the eDirectory it is recommended to tune this so it uses preferably the local server if this has a local replica, or a server on the local subnet that does have a replica of the needed tree partitions.

By default the “preferred-server” is set to the first Novell Open Enterprise Server that was installed in the eDirectory tree, so there is a huge chance this parameter requires adjustment.

To get the current namcd configuration execute as root:

namconfig get

If the preferred-server value does not point to the local ip address (which is preferred even when the server does not have a local replica), or an IP address of a server on the same physical subnet, this can be changed with the following sequence of commands as root:

namconfig set preferred-server=[local ip address (*)]

namconfig -k

namconfig cache_refresh

(*) When in doubt use ‘ndsconfig get’ and use the ip address listed in n4u.server.interfaces without the @524.

Alternatively, if the server does not have a local replica, it is also possible to add one or a couple alternative LDAP servers.

Adding a single alternative LDAP server is possible by executing this command as root:

namconfig set alternative-ldap-server-list=[ds-server01]

Adding more than one alternative LDAP server is possible using a comma separated list and can be accomplished by executing the following command as root:

namconfig set alternative-ldap-server-list=[ds-server01],[ds-server02],[ds-server03]

The usage of alternative LDAP servers for LUM can also be used to make LUM more scalable.

It is also recommended to turn persistent search off and cache-only on.

This can be accomplished by executing these commands as root:

namconfig set persistent-search=no

namconfig set cache-only=yes

As the namconfig cache_refresh includes a restart of the namcd there is no need to restart this daemon to enable these changes.

For the other changes and tunings to be enabled, it is recommended to restart the namcd.


Although it is required to tune Novell Storage Services to the requirements of the environment it is being used, these are some tunings worth considering:

– Increase the NSS IDCacheSize to 128K, this can be accomplished by executing, as root:

nsscon /idcachesize=131072

– Disable the Access Time by executing the following line as root:

nsscon /noatime=[volume name]

– From OES2SP2 onwards the Unplugalways parameter has a default value set to “off”. If this is not the case, disable it by executing as root:

nsscon /nounplugalways

More details can be found in “UnplugAlways Command for the Read Queue” in “Cache Management Commands” of the “NSS Commands” section in the OES2015 Documentation.

In order to make these tunings persistent they must be added (as by default they are not there) to the /etc/opt/novell/nss/nssstart.cfg, though make sure to make no typos in this file, as they can cause novell-nss to fail to start.

Make sure that all unmarked entries in this file start with “/” and not “nss /“.

Using nssmu, launched as root, increase the “read ahead blocks” for all nss volumes from the default value of 16 to 64.

If over time this appears to be insufficient, this can be increased to 128. It is not really recommended to go beyond this value, as it may have a negative impact on the performance.

This change is activated “on the fly”, and does not require a server restart.
Furter information regarding tuning NSS performance can be found in “Tuning NSS Performance” in the “NSS File System Administration Guide for Linux” of the OES2015 Documentation.

During the lifespan of a NSS Volume it is recommended to preserve at least 10% to 20% free space. Available purgable disks pace does not equal to true free disk space that is available.

Once a volume drops below these thresholds and there is insufficient true free disk space is available to the system to write data, a background process starts calculating what is the oldest deleted data that can be purged for the system in order to make space available for the new data to be written to disk..When there are large amounts of purgable data, nearly no true free space and large amounts of data is written this calculation process becomes a thread that will cause continuous I/O, performance degradation and other unwanted phenomena up to data corruption or loss.

For this reason it is recommended for NSS volumes hosting services with a high usage of temporary files to mark either the folders used for temporary storage or the volume as “purge immediate”, basically disabling salvage for those directories or the volume.

When a volume passes these thresholds it is recommended to either expand the pool and volume, delete obsolete data but a temporary measure may be to manually purge the volume.

This can be accomplished by executing the following command as root:

ncpcon purge volume [volume name]

However, as storage areas have become greater over time, grown into the terabytes (TB) keeping 20% free space might be a bit too much.

In case the NSS Pool size is in the TBs or larger, it might be worthwhile to consider lowering the PoolHighWaterMark and PoolLowWaterMark that is used for these large NSS Pools.

More details on this can be found in the “Salvage and Purge Commands” of the OES2015 documentation

After adjusting the PoolHighWaterMark and PoolLowWaterMark the behavior of the server will be the same when dropping below the set WaterMarks.

SMS (tsafs / backup)

In case you are suffering from slow performing back-up, or regressing back-up speed, the documentation for optimizing sms on OES2015 can be found in “Optimizing SMS” in the “Storage Management Services Administration Guide for Linux” of the OES2015 Documentation.


In a cluster environment, where a single OES2015 server might be hosting several NSS, NSSforAD, NCP and CIFS volumes at once, it is recommended to use lower cache values compared to a standalone OES2015 server.

The OES2015 cluster node must be able to handle the cache and memory requests when it is hosting all cluster resources at once.

All the previous steps should also address most issues seen with OES2015 servers running Novell Cluster Services and their cluster-enabled resources.

Non the less, if you are suffering from random split brains, without a physical reason (LAN or SAN outage), it would be advisable to investigate if there are time-jumps (back and or forward) caused by the CPU. Clock Jumps can occur on physical and virtual CPU’s and is not restricted to either of those.

In some cases where Novell Cluster Services are not starting up properly at boot-up, it is recommended to alter the /etc/sysconfig/boot so it reads RUN_PARALLEL=”no”.

This to allow the Novell services to start in their proper sequence and is the default for OES2015.

PKI (Certificate Server)

During the installation of any OES server, a couple default Server Certificates are generated.

These are by default valid for 2 years. After this period, when the certificates expire the server and all servers that use the server as LDAP source will no longer be able to access the required eDirectory information and all services that rely on it will fail.

Therefor it is recommended to validate the Default Server Certificates when some or all services of a particular server fails as one of the troubleshooting steps. If the failing server is using a different server as preferred_server, or LDAP source, that particular server’s Default Certificate Material should be checked too.

The LDAP servers that the server might be using are listed under /ets/sysconfig/novell/ldap_servers/ though it is recommended to also check each service to determine which LDAP server it is using, as they may differ.

A method of validating the Default Certificates of a server is via iManager.

This can be accomplished under the “Novell Certificate Access”, the “Server Certificates” task.

If one or more certificates is deemed invalid, the next step would be to repair these.

This task can be accomplished under “Novell Certificate Server”, the “Repair Default Certificates” task.

More details on this can be found in TID 7000075 “SSL Certificates expire after two years, affecting OES Services”

In case the LDAP server being used is a Novell NetWare server, these tasks can also be accomplished using the pkidiag.nlm

After the Certificates were replaced or repaired, it is recommended to at least restart the ndsd (rcndsd restart) so the server is using the new certificate for it’s LDAPS communication and run a namconfig -k to update the certificate that namcd is using.

A more sustainable option might be to enable “Self-Provisioning” for the Certificate Authority (CA) of the tree.

This feature is described here in the Novell Documentation.

Enabling this for the CA of the tree, this feature is enabled for all servers in the tree that use this CA.

As soon as the server or it’s ndsd is restarted it will be aware that “Server Self Provisioning” is enabled.

With this feature enabled, the certificates that are expired or about to be expired are extended automatically when executing either:


unload pkiserver

load pkiserver


rcndsd restart

Anti-Virus scanners:

When an Anti-Virus suite is installed, try to avoid the usage of “on access” scanning, as this can create a severe overhead.

The Anti-Virus suite, running either locally or remotely, should be excluded from scanning system crucial directories like the ._NETWARE of all NCP exported filesystems (both NSS and POSIX), /_admin and the Linux System directories.

In case Novell Cluster services is installed, /admin should also be excluded from being scanned by the anti-virus.

In case Novell GroupWise is installed, all repository and queue directories should be excluded from being scanned by the anti-virus as well. Novell GroupWise stores it’s information in an encrypted way, so scanning the physical files stored on disk is unnecessary and can even cause severe problems like file locking or even corruption.

There are several Anti-Virus suites that can scan inside the Novell GroupWise mail storage and / or incoming e-mail.


7018164: Enabling eDirectory’s event caching: Journal Event Caching vs. XDAS/CEF caching

eDirectory has two event caching mechanisms. Each is separate and helps solve one of the challenges outlined above.

Journal Event Cache

Description: this cache applies to ALL journal events: ndstrace, XDAS, NAudit, IDM events, etc. A location on disk can be set to store cached events. This location will be used rather than memory when the number being created becomes greater than the number that can be processed. This cache resides in the NDSD event system and is at a lower layer than the XDAS cache.

Pros: this helps reduce NDSD’s memory footprint by storing those events not yet processed to disk instead.

Cons: consumes additional disk space but compression lowers this requirement. It can also be slower to process the events since they must first be written to then retrieved from disk rather than memory.

Configuration: this cache’s settings are controlled via environment variables set in the ndsd script.


Enables the Journal Event Cache.


Sets the cache directory. Optional, default for Linux is /var/opt/novell/eDirectory/data/ and the dib directory for Windows.
As these are environment variables these are set in the following locations:
init.d: /opt/novell/eDirectory/sbin/pre_ndsd_start
systemd: /etc/opt/novell/eDirectory/conf/env

– There is no Journal Event cache setting for specifying the size. The Journal cache will use file sizes of 4MB or less while implementing its own compression upon them.

XDAS Cache

Description: The cache is implemented in the xadauditds layer and is ONLY used when:

1. XDAS specific events are ready to be sent to a remote auditing server.


2. The remote server cannot be reached.

Pros: Prevents the loss of audit event information when a remote audit server cannot be contacted. This cache is only used when required. The events are released once the remote server’s connection is reestablished.

Cons: other than some additional disk space used, none since it is only used if there is a problem.

Configuration: this cache’s settings are controlled via variables set in the xdasconfig.properties file.

– log4j.appender.S.CacheEnabled

Enables the XDAS Cache for storing XDAS events locally.

– log4j.appender.S.CacheDir

Optionally specifies the directory to use (/var/opt/novell/eDirectory)


Specifies the maximum file size. Values can be from 50MB to 4GB. The default is 512MB.

These cachemethodscan be used together. Consider the following scenario.

a. An XDAS audit event for a login is thrown but its reporting to the consumer is delayed behind other earlier events. The event gets written to the Journal Event Cache.

b. The Journal thread comes along and releases this event from the Journal Cache.

c. The configured remote audit server cannot be contacted. The event goes into the XDAS Cache.

d. The remote server is brought online again. The event is released from the XDAS cache and sent to a remote syslog appender.

More information can be found in the eDirectory Admin Guide found here: https://www.netiq.com/documentation/

CEF Cache

As with XDAS this cache is implemented in the audit layer and is ONLY used when:
1. CEF specific events are ready to be sent to a remote auditing server.


2. The remote server cannot be reached.
The auditlogconfig.properties file should be modified to change the log4j.appender.S.CacheEnabled property to a value of ‘yes’. It is also suggested to specify a value for ‘log4j.appender.S.CacheDir’. Setting this as well as eDirectory
s RFL directory to a a drive other than that occupied by the dib can both boost performance.

More information can be found in eDirectory’s Admin Guide under ‘Auditing with CEF’ – ‘Enabling CEF event caching’.


7023494: iMonitor cache statistics are incorrect if hit count exceeds 4GB

Using LDAP cn=monitor data, wecan see that the values in eDirectory are valid and not rolled at the 4,294,967,296 boundary (32-bit integer); this is just an issue with iMonitors handling ofthe data.



As a workaround, clear statistics and monitor afresh, it will take some time to reach the 4,294,967,296 limit or retrieve the values using an LDAP browser and perform a manual calculation.


7018598: Quickstart Guide: Setting up Active Directory Single Sign-On (SSO) with a GroupWise 2014 R2 SLES11 Linux Post Office


a. For the example purposes of this document, it is assumed thatthe GroupWise Linux Post Office Server fully qualified hostname is“bperez13.bperez11.gwlab.com” and that the Active DirectoryDomain Server fully qualified hostname is “bperez11.gwlab.com”. Substitute your hostnames as appropriate.

Inthis example the User in Active Directory and the GroupWise UserID is“aduser1” that we will work with. Your SLES11 server is upto date on patches.

b. It is assumed that in your Microsoft Active Directory Server,DNS Manager, that you have a DNS “zone name”, in thisexample, of “bperez11.gwlab.com”, but substitute yourDNS zone name, that way you will not have to make changes to theGroupWise Linux server hostname and POA agent settings hostname onthat server.

c. It is assumed that you have or will have a DNS “A”Record (on your Microsoft Domain Server) of , in this example,bperez13.bperez11.gwlab.com, substitute your GroupWise server fullyqualified hostname as needed. So in this example in theMicrosoft Domain Controller Server, in the DNS application, under”Forward Lookup Zones”, you would have defined a DNS zonecalled “bperez11.gwlab.com” and under this zone you wouldcreate a DNS A record that would have a “Host” name of”bperez13″ and a “Fully qualified domain name (FQDN)of “bperez13.bperez11.gwlab.com” along with the ip addressthat resolves to bperez13.bperez11.gwlab.com. Make the propername substitutions as you need.

d. It is assumed you are working with a Microsoft Windows 2012 R2Server.

e. It is assumed that you have created an Ldap Directory and LdapServer in the GroupWise Web Admin Console under SYSTEM, “LdapServers” by following the steps listed in Section 6.1 , steps 1thru 6 of this URL :


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


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

g. Lastly it is assumed on your Active Directory Windows Server 2012 R2box, in “Active Directory Users and Computers”, View, that youhave “checked”, “Advanced Features”.


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


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

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

Stepsto Follow :

ForLinux Post Office Server you will have to “Join” theWindows Server Domain Controller and make the below changes NOW :

1. You need to know the current fully qualifiedhostname for the Linux GroupWise Post Office Server, let”s sayit is:

a. bperez13.bperez11.gwlab.com

2. You need to know current fully qualified hostnamefor your Active Directory Domain Server, let”s say it is:

a. bperez11.gwlab.com

3. Then the Linux Post Office Server will likelyneed a change to it’s listed “Name Server” in YAST, in thisexample: ( 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,

andin the Hostname/DNS tab, the “Hostname” would have to be”bperez13“, no

quotes,and the “Domain Name” would have to be : “bperez11.gwlab.com”, no quotes. As

appropriatein your situation, change it NOW.

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

addressof your Active Directory Domain Controller. Do not have anyvalues for

“NameServer 2” and “Name Server 3” . The “DomainSearch” list box to the

rightwould have to show – “bperez11.gwlab.com”, no quotes. Asappropriate in your situation, change it NOW.

d. The Routing tab, the “Default Gateway”,would of course have to be filled out correctly

foryour 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 ipaddresses or hostnames to make sure you have proper ip connectivity.

4. Go to the below documentation URL for “ConfiguringSingle Sign-On with Active Directory” (54.2):

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

b. With the above GroupWise documentation URL, under thesection “Configuring Single Sign-On with Active Directory”(54.2), we will go over the listed first 4 bullet points inorder:

c. For the 1st bullet point, make sure both the POA LinuxServer and the User Windows Workstation are joined to the sameActive Directory Domain:

i. On the Linux box where the Post Office is located,Click Computer, Yast, Network Services, Windows Domain Membership, onMembership “Domain or Workgroup”, type the fully qualifiedhostname NOW for your Active Directory Domain Controller, in thisexample, but substitute yours :


ii. Click the Expert Settings button, for the KerberosMethod select “system keytab”, then Click OK.

iii. Click the “NTP Configuration” button, toensure time synchronization between the Linux Post Office Server andthe Active Directory Domain Server, as needed, set the Time server. Click ADD, Click Next, Type in an appropriate local or publicTime Server, Click Test, Click OK after it responds correctly, ClickOK, then OK again. Click the JOIN button in upper right ifpresent, otherwise Click OK. ClickOK again. You should see a dialog that pops up that says “Thishost is not a member of the domain <bperez11>”. Youwill see another dialog that says “Join the domain <bperez11>?”, Click Yes. Inthe resulting dialog put in the Windows domain controller“administrator” username and password and CLICK OK.

iv. Your Linux Server is now Joined to the Active DirectoryServer.

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

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

2. For the “User the following DNS Serveraddresses:”, for the “Preferred DNS server”, type theIP address of your Active Directory Server. Click OK then CLOSE.

3. Now to actually Join to the Active Directory Server, goto :

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

b. For the Member Of : Domain , list box , type the fullyqualified hostname of the Active Directory Server (example,bperez11.gwlab.com). Click OK. Supply the appropriateActive Directory credentials, Click OK, then you should successfullyJoin and get a confirmation on this. Click OK. Click OKagain to RESTART your computer as required by Windows. I assumeyou will Click RESTART NOW.

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

i. The name of your Windows Domain ServerA.D. UserName,example, in this case is “BPEREZ11aduser1”

ii. Type the password for this Active Directory User andLOGIN

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


e. Close the DOS Window.

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

“Makesure the POA object has the DNS fully qualified domain name insteadof the IP address :

Inthe GroupWise Admin Console > Post Office Agents > select thePOA

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

Inthis example, the value should already be: “bperez13.bperez11.gwlab.com”. Make this changeas needed NOW if necessary. Remember no I.P. Address, just thehostname.

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 sureyour A.D. Ldap Server name is selected here. Refer to aboveAssumptions point “e” for details if needed.

h. For the 4th bullet point of the DocumentationURL: “Select Network authentication (eDirectory or ActiveDirectory) in the Admin Console > Post Office Agents > selectthe POA > Client Options > Security tab. Do this changenow. Remember to Click on SAVE.

Nowit”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 thatall krb5 rpms are installed on the server”. This meansthat you should check in YAST, Software Management, search, type”krb5″, no quotes and click the SEARCH button.

a. Youshould have “checked” “krb5”, “krb-32bit”,AND “krb5-client”, if you don’t have all of these check offthe missing one and CLICK the ACCEPT button in the lower right of thedialog. Exit YAST.

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

a. rpm-qa | grep krb5

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

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

Wealready did this. Next step.

7. 3rd bullet point, “Join the Linux POA server tothe Windows Domain by”.” :

Wealready did this. Next step.

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

vi/etc/krb5.conf :


default_realm= BPEREZ11.GWLAB.COM

clockskew= 300



kdc= bperez11.gwlab.com

default_domain= bperez11.gwlab.com

admin_server= bperez11.gwlab.com



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

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



.bperez11.gwlab.com= BPEREZ11.GWLAB.COM

bperez11.gwlab.com= BPEREZ11.GWLAB.COM

9. 5th bullet point, at a terminal on the Linux PostOffice Server, as “root”, issue this command NOW : NOTthe command in the documentation, unless it is the same :

a. net -Uadministrator@<activeDirectoryFullyQualifiedHostName> adskeytab add groupwise

b. Type the password for Active Directory “administrator”user

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

i. <a number>groupwise/bperez13.bperez11.gwlab.com@bperez11.gwlab.com

ii. You MUST see this fully qualified domain name, yourswill be different, that is to the left of the “@”character, “bperez13.bperez11.gwlab.com”

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

Soif you run the GroupWise agents as “root”, or another

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

Sowhen you go to the /etc/ directory on the Post Office Linux Serverand issue the command, as “root”, “ls -lkrb5.keytab” , no quotes.

Youwill see the owner of the file, root is the owner here :

a. -rw- – – – – – – 1 root root 2027 Jan 2215:16 krb5.keytab

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

terminal: “ps -eaf | grep gwpoa”, no quotes, the owner is in thefirst left most column.

Ifit says “root” then there is a match and the ownership ofthis file is good. If there is not a match, then you MUSTchange 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. Ifthe user is not the “root” user then, let”s say theuser is called “gwuser”, I assume that “gwuser”is part of the Linux group called “users”.

Thenyou must assign the appropriate user and group file permissions. Asappropriate do this NOW : either :

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

ii. chmod ug=rwx ./krb5.keytab

11. ( Optional ) 7th and final bullet point, “Create aGroupWise Name Server in DNS”. If you do not do this,users need to know the IP address and port number to connect to thePOA.

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


12. Note: In this example situation, when you start the GroupWiseWindows Client the first time after enabling Single Sign-On, youshould see the “Micro Focus GroupWise Startup” dialog, andin this dialog you “should” see “Connecting to Post Officeat : bperez13.bperez11.gwlab.com: 1677″. Substitute yourhostname for GroupWise. If you do not see the correct hostnameor you see an ip address, then just click CANCEL and correct the”Address” list box to show your GroupWise hostname, fillout the rest of the information needed in this dialog and CLICK OK. Now when you successfully login, it will remember your credentialsand the next time you attempt to login to GroupWise you should not beprompted for your password.


Ifyou follow this Document and if you have a problem where you arestill prompted for a password when attempting to login to theGroupWise Windows client and if you are on SLES11, it could be thatyou may have an older version of the linux Kerberos “krb5″files, you can review this TID on how to check on and correctthis issue :


Otherthings to check if you still are prompted for a password:

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

a. Chmodug=rwx ./krb5.keytab

2. Verifyon the Windows Domain Controller server (Windows Sever 2012 R2), inthe application “Active Directory Users and Computers”, under theActive Directory Organization called “Computers” has an objectcalled the name of your GroupWise Linux Post Office Server name. Under this object, go under Properties, Attribute editor tab, youshould have an attribute called “servicePrincipalName”. Ifyou edit this attribute, you should see among other things,“groupwise/bperez13.bperez11.gwlab.com” . No quotes, andsubstitute your GroupWise Post Office Server hostname.

3. Fromthe perspective of the user, in Windows, in the GroupWise Windows14.2.2 client, click on Tools, Options, Security, Password tab, atthe bottom you should have a checkmark in the checkbox “No passwordrequired with eDirectory”. If you do not, Single Sign-On willnot work. If it is not “checked”, just type in yourpassword in the “Old password” listbox, then the checkbox willnot be greyed out, so you can check it. Then click APPLY andOK. Then exit the GroupWise Windows client and re-login.

4. Alsoon the user Windows workstation, go to the Dos Window ( cmd ) , andcd to : c:windowssystem32 , then type the command “klist” noquotes, you should see among other things a reference to theGroupWise Kerberos ticket, for me is shows :

Client: aduser1 @ bperez11.gwlab.com

Server: groupwise/bperez13.bperez11.gwlab.com @ bperez11.gwlab.com

KerbTicketEncryption Type: RSADSI RC4-HMAC(NT)

TicketFlags 0x40a10000 -> forwardable pre_authent name_canonicalize

StartTime: 1/9/2018 8:01:23 (local)

EndTime: 1/9/2018 16:31:30 (local)

RenewTime: 1/16/2018 6:31:30 (local)

SessionKey Type: RSADSI RC4-HMAC(NT)

5. If Single Sign-On is till not working, (you are being prompted for apassword, then do the below, after hours, so not to potentiallyaffect Post Office users, you will be toggling some settings underthe Post Office and POA objects :

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

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

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

Checkingstatus [provo.utah] running”

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

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


7023371: Unable to change AD password if using restricted (non-domain Admin) rights

This document (7023371) is provided subject to the disclaimer at the end of this document.


Identity Manager Driver – Active Directory


Error when changing a user’s password in Active Directory when using a user with only limited rights in Active Directory. When using a user with Domain Admin rights in Active Directory, the password is changed successfully.
Error is as follows:
<status level=”error” type=”driver-general” event-id=”….”>
<message>Password set failed.</message>
<ldap-err ldap-rc=”50″ ldap-rc-name=”LDAP_INSUFFICIENT_RIGHTS”>
<client-err ldap-rc=”50″ ldap-rc-name=”LDAP_INSUFFICIENT_RIGHTS”>Insufficient Rights</client-err>
<server-err>00000005: SecErr: DSID-031A11D7, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0
<server-err-ex win32-rc=”5″/>


This may be caused if the user does not have all the rights needed to change the password.
With Windows server 2016, you may find that additional rights are needed.
Also based on your security policies changes may be needed.
Below is one possible configuration that may work depending on the setup of the domain. Because of the countless ways a domain may be configured and the ways a driver may be configured, only suggestions may be made.
Grant the user the following permissions:
Replicating Directory Changes
Replicating Directory Changes All
Replicating Directory Changes in Filtered Set
Replication synchronization
Also the following delegation:
Create, delete, and manage user accounts
Reset user passwords and force password change at next logon
Read all user information
It may also be caused if the user had ever been a member of a domain admin group or other security group that caused the user to receive the attribute admincount=1 in active directory. Even if the user is later removed from the security group, the attribute will often remain on the user.
Here is a command to check the user from a powershell prompt.
get -aduser <username> -Properties admincount
If admincount is set to 1, unless the driver is using a domain admin account, you will not be able to change the password.


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7023291: SSPR Users locked out after LDAP certificates are updated

This document (7023291) is provided subject to the disclaimer at the end of this document.


Self Service Password Reset
SSPR 4.x


Error 5017 authenticating to SSPR
Error 5059 – A certificate error has been encountered
Directory unavailable after certificates on the LDAP server were updated
Users unable to login after updating certs on LDAP server


Reset the LDAP certificates by deleting and re-importing them through SSPR Config Editor
Steps if using SSPR Appliance:
  1. Open the SSPR Appliance (port 9443) https://server.whatever.com:9443
  2. Open Administrative Commands
  3. Select Unlock configuration
  4. Open SSPR Configuration Editor by going direrectly to https://server.whatever.com/sspr/private/config/editor (you might need to use a browser other than IE)
  5. In Config Editor, select LDAP ⇨ LDAP Directories ⇨ default ⇨ Connection, LDAP Certificates
  6. Select Clear
  7. Select Import from server
  8. Save Changes
  9. Go back to the appliance (port 9443) https://server.whatever.com:9443
  10. Open Administrative Commands
  11. Select Lock configuration
Steps if using Linux (.war) or Windows (.msi) implementations of SSPR:
  1. Edit SSPRConfiguration.xml and set “configIsEditable” to true. It should look like this: <property key=”configIsEditable”>true</property> (for more detail see TID 7014954, “SSPR config manager not available” at https://www.novell.com/support/kb/doc.php?id=7014954
  2. Open SSPR Configuration Editor by going direrectly to https://server.whatever.com/sspr/private/config/editor (you might need to use a browser other than IE)
  3. In Config Editor, select LDAP ⇨ LDAP Directories ⇨ default ⇨ Connection, LDAP Certificates
  4. Select Clear
  5. Select Import from server
  6. Save Changes


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.


7014954: SSPR config manager not available

This document (7014954) is provided subject to the disclaimer at the end of this document.


Self Service Password Reset
SSPR 3.x
SSPR 4.x


Link to SSPR Configuration Editor is not shown on SSPR page
SSPR configuration has been locked
How to unlock SSPR Configuration Manager


For appliance installations of SSPR do the following:
  1. Go to the appliance administrative console at https://myserver.whatever.something.com:9443
  2. Select “Administrative Commands”
  3. Click “unlock configuration”

After you no longer need configuration to be unlocked be sure to select the option to lock the configuration when you are done.

For Linux or Windows (i.e. non-appliance) installations of SSPR do the following:
Edit the SSPRConfiguration.xml file. In Linux, this is found by default in the Tomcat directory under webapps/SSPR/WEB-INF. In Windows, this is found in by default in C:Program FilesNetIQ Self Service Password Resetconfig

Then restart the SSPR service.
Edit the SSPRConfiguration.xml as follows:
Set “configIsEditable” to true. It should look like this:
<property key=”configIsEditable”>true</property>
Also, if the configuration password has been forgotten or no longer works, delete the property “configPasswordHash”
<property key=”configPasswordHash”>

Additional Information

Note: SSPRConfiguration.xml can be edited with any text editor that can do UTF8 character encoding. Be sure to use a texteditor that can save UTF8. Notepad.exe can not save UTF8; Wordpad.exe can.


This Support Knowledgebase provides a valuable tool for NetIQ/Novell/SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented “AS IS” WITHOUT WARRANTY OF ANY KIND.