The logs show a mixture of sssd restarts, network restarts, going offline and online, it's difficult to pinpoint exactly when the login failed.
Right after you pull the network, I assume you have a local console still open. Have you checked what sssd thinks the online/offline status is? That can be done with the sssctl command. Here is what I do in my testing rig:
Active servers:
AD Global Catalog: not connected
AD Domain Controller: win-kriet1e5elo.internal.example.fake
Discovered AD Global Catalog servers:
None so far.
Discovered AD Domain Controller servers:
- win-kriet1e5elo.internal.example.fake
If it still thinks it's online, when in fact it isn't, and logins are failing, see if by forcing the offline mode you can make the logins work:
kill -SIGUSR1 $(pidof sssd)
You seem to have 4 DCs:
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc01.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc03.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc04.ibeo.as' is 'working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_port_status] (0x1000): Port status of port 389 for server 'dc04.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc02.ibeo.as' is 'working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_port_status] (0x1000): Port status of port 389 for server 'dc02.ibeo.as' is 'not working'
(Mon Jun 27 13:25:23 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc02.ibeo.as' is 'working'
I see a mix of them either "working" or "not working", or even "neutral". When you adjust /etc/hosts, do you pick one of them, or all 4?
Finally, the other difference you have to our testing rig (besides 4 controllers, and we only have 1) is probably group policies, although I see you have it set to "permissive", so it shouldn't block logins. But we don't have any GPO set here I believe (just defaults from a 2016 AD DC server).
The logs show a mixture of sssd restarts, network restarts, going offline and online, it's difficult to pinpoint exactly when the login failed.
Right after you pull the network, I assume you have a local console still open. Have you checked what sssd thinks the online/offline status is? That can be done with the sssctl command. Here is what I do in my testing rig:
# sssctl domain-status internal. example. fake
Online status: Offline
Active servers: .internal. example. fake
AD Global Catalog: not connected
AD Domain Controller: win-kriet1e5elo
Discovered AD Global Catalog servers: .internal. example. fake
None so far.
Discovered AD Domain Controller servers:
- win-kriet1e5elo
If it still thinks it's online, when in fact it isn't, and logins are failing, see if by forcing the offline mode you can make the logins work:
kill -SIGUSR1 $(pidof sssd)
You seem to have 4 DCs:
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc01.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc03.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc04.ibeo.as' is 'working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_port_status] (0x1000): Port status of port 389 for server 'dc04.ibeo.as' is 'not working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc02.ibeo.as' is 'working'
(Mon Jun 27 13:25:05 2022) [be[IBEO.AS]] [get_port_status] (0x1000): Port status of port 389 for server 'dc02.ibeo.as' is 'not working'
(Mon Jun 27 13:25:23 2022) [be[IBEO.AS]] [get_server_status] (0x1000): Status of server 'dc02.ibeo.as' is 'working'
I see a mix of them either "working" or "not working", or even "neutral". When you adjust /etc/hosts, do you pick one of them, or all 4?
Finally, the other difference you have to our testing rig (besides 4 controllers, and we only have 1) is probably group policies, although I see you have it set to "permissive", so it shouldn't block logins. But we don't have any GPO set here I believe (just defaults from a 2016 AD DC server).