Environment
NetIQ eDirectory 9.0
Situation
How does one temporarily disable Enhanced Background Authentication (EBA) on an eDirectory 9.0 server?
Turning on the EBA flag in dstrace shows the server's certificate is not yet valid (bad NTP).
eDirectory NCP traffic is encrypted and cannot be read via a LAN trace.
eDirectory will not start. The following is seen on the console:
Executing customized settings after starting the NetIQ eDirectory server...
NetIQ eDirectory LDAP Server is not listening on the TCP port.
Turning on the EBA flag in dstrace shows the server's certificate is not yet valid (bad NTP).
eDirectory NCP traffic is encrypted and cannot be read via a LAN trace.
eDirectory will not start. The following is seen on the console:
Executing customized settings after starting the NetIQ eDirectory server...
NetIQ eDirectory LDAP Server is not listening on the TCP port.
EBA was enabled erroneously and is restricting operations such as promoting a server to master of a replica ring.
Resolution
BACKGROUND
eDirectory Background Authentication provides single sign-on capability to both servers and clients. For example, a user establishes his initial connection and successfully authenticates to eDirectory. The authentication materials received can then be used to connect to any other server in the tree to which that user has rights without encountering an additional login prompt.
Enhanced Background Authentication (EBA) is eDirectory 9.0's new standards-based background authentication method. EBA provides the same ease of use while employing the stronger encryption ciphers that many standards organizations are recommending. Though most of EBA's benefit comes from having all eDirectory 9 servers in a replica ring it is also backward compatible. EBA will fall back to the older Background Authentication method if a pre-9.0 server is in the same replica ring.
IMPORTANT: Once EBA is turned on it is important to ensure the tree's EBACA is always reachable. Ideally, it is recommended to have one "lightly used but highly regarded" server act as the SDI domain server, RootCA, master of Root and the EBACA. Then disaster recovery becomes easier and mistakenly taking the wrong server out of a ring or the tree is less likely.
CRL Expiration: the EBACA is responsible for refreshing the EBA certificate CRLs. If the CRLs expire, server to server communications will stop. It is also important that NTP be used to maintain time. If the EBACA server thinks it is 1 week earlier than or 1 week later than current time the EBA certificates for other servers will no longer work. The current time would not match their validity date. The length of time the EBACA can remain unreachable before problem start and how to resolve this depends on the version:
9.0 & 9.0.1:
If the EBACA is down for longer than 3 days the CRLs will be expired. With these versions the refreshed CRLs can only be synchronized over the EBA protocol. To fix:
1. Restart servers with the environment variable mentioned above.
2. Allow servers to synchronize.
3. Restart servers without the environment variable mentioned above so EBA is reenabled on all servers.
9.0.2 and above:
If the EBACA is down for longer than 7 days the CRLs will be expired. With this version the refreshed CRLs can be synchronized over EBA as well as normal synchronization. To fix:
Once the EBACA is reachable again the CRLs should get refreshed automatically though it could take a little time depending on the number of servers in the tree. No other steps are required.
For all versions the +EBA flag in ndstrace should show when the refresh is successful.
TEMPORARILY DISABLING EBA
Once EBA is turned on it cannot be turned off.
However, it can be temporarily disabled for troubleshooting purposes or
to fix an issue. Once disabled, server to server communications falls
back to the older background authentication protocol. Once the issue is
resolved EBA should be re-enabled as soon as possible.
DISABLE_EBA is a new environment variable that will temporarily disable EBA functionality on an eDirectory 9.0 server as well as on NCP client applications.
Init.d Linux:
Export this environment variable and restart NDSD.
Example: DISABLE_EBA=true /etc/init.d/ndsd restart
Windows:
Go to Control Panel > System > Advanced System Settings > Environment Variables > System Variables > New. Add a new variable called DISABLE_EBA with value 1 and restart the server.
NOTE: Once the server issue is resolved it is recommended to restart the server in EBA mode as soon as possible to avoid any login problems due to expired CRLs.
TIME: Good timesync is crucial for EBA to function. The certificates can run into problems if there is a time variance of greater than 10 minutes between the servers.
eDirectory Background Authentication provides single sign-on capability to both servers and clients. For example, a user establishes his initial connection and successfully authenticates to eDirectory. The authentication materials received can then be used to connect to any other server in the tree to which that user has rights without encountering an additional login prompt.
Enhanced Background Authentication (EBA) is eDirectory 9.0's new standards-based background authentication method. EBA provides the same ease of use while employing the stronger encryption ciphers that many standards organizations are recommending. Though most of EBA's benefit comes from having all eDirectory 9 servers in a replica ring it is also backward compatible. EBA will fall back to the older Background Authentication method if a pre-9.0 server is in the same replica ring.
IMPORTANT: Once EBA is turned on it is important to ensure the tree's EBACA is always reachable. Ideally, it is recommended to have one "lightly used but highly regarded" server act as the SDI domain server, RootCA, master of Root and the EBACA. Then disaster recovery becomes easier and mistakenly taking the wrong server out of a ring or the tree is less likely.
CRL Expiration: the EBACA is responsible for refreshing the EBA certificate CRLs. If the CRLs expire, server to server communications will stop. It is also important that NTP be used to maintain time. If the EBACA server thinks it is 1 week earlier than or 1 week later than current time the EBA certificates for other servers will no longer work. The current time would not match their validity date. The length of time the EBACA can remain unreachable before problem start and how to resolve this depends on the version:
9.0 & 9.0.1:
If the EBACA is down for longer than 3 days the CRLs will be expired. With these versions the refreshed CRLs can only be synchronized over the EBA protocol. To fix:
1. Restart servers with the environment variable mentioned above.
2. Allow servers to synchronize.
3. Restart servers without the environment variable mentioned above so EBA is reenabled on all servers.
9.0.2 and above:
If the EBACA is down for longer than 7 days the CRLs will be expired. With this version the refreshed CRLs can be synchronized over EBA as well as normal synchronization. To fix:
Once the EBACA is reachable again the CRLs should get refreshed automatically though it could take a little time depending on the number of servers in the tree. No other steps are required.
For all versions the +EBA flag in ndstrace should show when the refresh is successful.
TEMPORARILY DISABLING EBA
DISABLE_EBA is a new environment variable that will temporarily disable EBA functionality on an eDirectory 9.0 server as well as on NCP client applications.
Init.d Linux:
Export this environment variable and restart NDSD.
Example: DISABLE_EBA=true /etc/init.d/ndsd restart
Systemd Linux:
If running on a systemd OS, such as SLES 12 or RHEL 7.4 simply modifiy the /etc/opt/novell/eDirectory/conf/env file and place the environment variable there. For example, add the following line to /etc/opt/novell/eDirectory/conf/env file:
DISABLE_EBA=1
Then restart eDirectory:
ndsmanage stopall
ndsmanage startall
Windows:
Go to Control Panel > System > Advanced System Settings > Environment Variables > System Variables > New. Add a new variable called DISABLE_EBA with value 1 and restart the server.
NOTE: Once the server issue is resolved it is recommended to restart the server in EBA mode as soon as possible to avoid any login problems due to expired CRLs.
TIME: Good timesync is crucial for EBA to function. The certificates can run into problems if there is a time variance of greater than 10 minutes between the servers.
Additional Information
This environment variable can also be set before running 'ndslogin' to prevent 'ndslogin' from using any EBA functionality.
The parameter, n4u.server.eba_enabled, in the nds.conf file is what ndsconfig uses to determine if EBA is enabled on the server. This setting does not actually configure EBA on the server but utilities will check this setting to see if it has. If this is enabled the following conditions apply:
- The admin is no longer prompted on whether to enable EBA.
- Ndsconfig will no longer accept the "--configure-eba-now=no" argument.
- eDirectory utilities will prevent partition operations that could potentially break EBA. (An example would be iManager refusing to allow a replica of root to be removed from the current EBACA server.)
- After disabling EBA, if you are trying to promote a server to master of a replica ring, 'ndsrepair -P option 5' may fail with error -632. If this occurs, simply use iManager to promote it to master instead.
Enabling Enhanced Background Authentication
The parameter, n4u.server.eba_enabled, in the nds.conf file is what ndsconfig uses to determine if EBA is enabled on the server. This setting does not actually configure EBA on the server but utilities will check this setting to see if it has. If this is enabled the following conditions apply:
- The admin is no longer prompted on whether to enable EBA.
- Ndsconfig will no longer accept the "--configure-eba-now=no" argument.
- eDirectory utilities will prevent partition operations that could potentially break EBA. (An example would be iManager refusing to allow a replica of root to be removed from the current EBACA server.)
- After disabling EBA, if you are trying to promote a server to master of a replica ring, 'ndsrepair -P option 5' may fail with error -632. If this occurs, simply use iManager to promote it to master instead.
Enabling Enhanced Background Authentication