Cacti 1.2.5 AD authentication and account templates

[sdunne]

Hi there

Running cacti 1.2.5 and having problems with multi AD domain based authentication.

I'm currently authenticating against a single AD domain, but the account creation for a new eligible AD logon seems to be borked and is throwing an error.

Code: Select all

2019/08/07 16:37:33 - CMDPHP PHP ERROR NOTICE Backtrace: (/index.php[25]:include(), /include/auth.php[167]:require_once(), /auth_login.php[175]:domains_login_process(), /auth_login.php[542]:CactiErrorHandler())  
2019/08/07 16:37:33 - ERROR PHP NOTICE: Undefined offset: 0 in file: /var/www/html/cacti-1.2.5/auth_login.php on line: 542  

admin domain is configured as follows:

User Domain
=========
Name: Admin
Domains Type: AD
User template:admin-template
Enabled: Yes

Domain Props
==========
Server: <DC IP>
Port Standard: 389
Port SSL: 636
Protocol: V3
Encryption:None
Referrals: Disabled
Mode:Specific Searching
DN: None
Require group Membership: Off

LDAP Specific Search Settings
Search Base: OU=Employees,OU=xxxx,DC=admin,DC=xxxx,DC=corp
Search Filter: (&(objectclass=user)(objectcategory=user)(userPrincipalName=<username>*))
Search DN: CN=cactildapuser,OU=Employees,OU=xxxx,DC=admin,DC=xxxx,DC=corp
Search password: <cactildapuser password>

LDAP CN Settings:
Full Name: displayName
eMail: mail

When an eligible user attempts to login for the 1st time I get the following log entries from bottom to top:

Code: Select all

2019/08/07 16:37:33 - AUTH WARN: User 'adm-yyyyyyy' does not exist, copying template user  
2019/08/07 16:37:33 - AUTH LOGIN: LDAP User 'adm-yyyyyyy' Authenticated from Domain 'admin'  
2019/08/07 16:37:33 - AUTH LDAP_SEARCH: Authentication Success, DN: CN=<users Name>,OU=EMEA,OU=ADMIN,OU=Employees,OU=xxxx,DC=admin,DC=xxxx,DC=corp 

So far so good. The account gets created with the correct name adm-yyyyyyy, but the Full Name and the email address fields are copied from the template, rather than being overwritten by the field contents from the matched AD record as denoted in the "LDAP CN Settings" as well as getting the error as mentioned at the top of the post.

[netniV]

Yes, I believe that is as expected since we don't know what the fields are that be used to contain then since different systems can hold it in differently named ldap fields.

[netniV]

If you can log the bad index and stack trace on github though, we can get that fixed