Last Modified: Jun 19, 2025
Affected Product(s):
F5OS F5OS, F5OS-A
Known Affected Versions:
F5OS-A 1.8.0
Fixed In:
F5OS-C 1.8.1
Opened: Dec 31, 2024 Severity: 2-Critical
After an rSeries appliance reboot, Active Directory LDAP authentication configured with "Unix Attributes" set to false does not work and users from Active Directory are unable to authenticate with the F5OS system. There will be messages similar to the following logged in platform.log shortly after the reboot: authd[8]: priority="Err" version=1.0 msgid=0x3901000000000101 msg="LDAP API error during : -" oper="SASL bind" code=-1 msg="Can't contact LDAP server". authd[8]: priority="Warn" version=1.0 msgid=0x3901000000000098 msg="Unable to retrieve domain Sid for supplied servers and domains; server will be treated as if it has unix attributes present.".
LDAP remote authentication does not work.
- F5OS device configured with Active Directory LDAP authentication, and the "Unix Attributes" setting configured as false. - System reboots
To workaround this issue on an rSeries appliance, create a cron task to restart the system_user_manager and authentication-mgr docker containers after a system reboot: 1. Log into the system as root and create /etc/cron.d/ldap-post-reboot with these contents (not including the '==='): === # Workaround for post-reboot issue with LDAP auth (ID1782925) # # In the the first five minutes after the system reboots, assume the first # instance of the following log message that we see is a result of the management # port lack of connectivity when the docker containers start up, and restart both # system_user_manager and authentication-mgr once. # # authd[8]: priority="Err" version=1.0 msgid=0x3901000000000101 msg="LDAP API error during : -" oper="SASL bind" code=-1 msg="Can't contact LDAP server". @reboot root timeout 5m sh -c 'tail -n0 -F /var/F5/system/log/platform.log | grep -a -m1 authd.*0x3901000000000101 && sleep 20s && echo Restarting authd and user-manager && docker restart system_user_manager authentication-mgr' || echo "Timed out" === This mitigation may fail under some corner cases, e.g. potentially after an upgrade or if something goes wrong with the platform services such that they don't start up within the first five minutes after system boot. In those circumstances, log into the system as root and restart the system_user_manager and authentication-mgr containers: docker restart system_user_manager authentication-mgr
None