php72u indicates your serve is using IUS repo ... https://ius.io/ for PHP.
yum repolist will show what repos you server will acquire updates from.
https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/repoview/
Why it's important you know that ... repos can provide an update that you don't want ... just yet. Moodle code has not been tested with all latest/greatest yet ... like MySQL vr 8.
On your server it might be wise not to allow those repos to autoupdate. Set of that beyond the scope of Moodle forums but do suggest you investigate your servers yum and repo setups.
"... the password stored in Moodle is the one that LDAP would use too?"
normally, remote authentications in moodle do NOT store password in moodle mdl_user tables or other authentication tables. I use Google Oauth2 on several servers and I would not want Moodle to store password in moodle.
"Is there anything obvious that need to change in the LDAP Moodle settings or configs when moving/archiving a Moodle install?"
Networking comes before application ... so if LDAP server is protected by some setting as to what internet servers can access/use it for authentication, then your new moodle (new IP) may not be in an allowed list ... something like that. LDAP/AD changes so a change to LDAP/AD might/would affect moodle's use of it. LDAP/AD admins might make a change that inadvertently affects Moodle. So make sure your LDAP/AD server admin is aware.
'SoS', Ken
Couple of more thought ... if you didn't have php72u-cli installed what about php72u-ldap?
The only reason for setting authentications via config.php was to get around issues with LDAP. Comment out that line in config.php. After that, whatever authentications are enabled come into play again.
LDAP authentications enabled?
There is a CLI script in moodlecode/admin/cli/ called cfg.php.
Execute like : php cfg.php (now that you have CLI).
Look for settings related to authentications.
php cfg.php |grep auth
Your getting closer to resolution now!
'SoS', Ken
Network techs have been known to be wrong ... not intentionally ... so my advice is to test yourself using nmap.
nmap -P0 -p LDAPPORT IPADDRESSOFLDAPserver.
A real one:
nmap -P0 -p 389 172.25.84.30
would show:
389/tcp open ldap
Means moodle server can talk to ldap on port 389 ... open.
On a server using LDAP for students only I do have openldap.x86_64 and openldap-clients.x86_64 installed even though Moodle doesn't really need it. Comes into play testing however.
Are you using Moodle Networking? That's the mnet in your auth ... shows it's turned on ... if not using, turn it off.
Yep, that ldapsearch command is 'involved' and not really a user friendly tool ... unless you are into LDAP. Am not myself.
For 'easier' testing and admin of a server I usually install Webmin - open sourced cPanel. It has it's own perl based web service one runs on ports like 100000 and a web based LDAP search that allows one to view the tree/forest/OU's etc. but not edit them - which is all you need for Moodle.
https://doxfer.webmin.com/Webmin/LDAP_Client
You do have to set that up to talk to an LDAP server with a user that can query the tree/forest whatever.
Once you do that successfully - which would have same settings one would use in Moodle for the BIND user, one can drill down via it's LDAP Browser into LDAP to find the OU's that contain users ... internet Schema ... which is the stuff moodle uses.
Can't share a screen shot as that would disclose too much info.
'SoS', Ken
Is there an auth line in config.php which doesn't include ldap? If line exist, it controls what can be enabled. Comment line out (// in front). Then see if you can enable.
'SoS', Ken