LDAP and OAUTH setup issues

bugeater87

Hi All:

Setting up a new server to move OSTicket on. Got everything planned for the migration but have not been able to make LDAP or OAUTH work.

Running Windows Server 2019 standard, Apache 2.4.53 (win 64) and openSSL 1.1.1, MySQL 5.5.65, and PHP 8.1.6.

For LDAP, verified I have full network open between the server and DC but when turning on use TLS, errors out with cannot bind. no logs to help identify issue.

Also trying to setup OAUTH. Got it connected and it launches login screen. After login from Msft, get invalid path error looking for /api/auth/oauth2. Which shows in the error logs but still no indication why. Looking at the server under the htdocs folder there is an /api folder but no /auth subfolder. On the setup screen, it has the server/api/auth/oauth2 path in the redirect URI.

Any thoughts on what I'm missing or places to check to get primarily OAUTH working?

Regards
Bugeater87

KevinTheJedi

bugeater87

Please read the existing threads here on these two separate issues. There have been answers given in such threads already.

I will say the the URL not found is due to URL rewriting not being enabled or the current rewrite rules you are using are borked. Again, the fix has been suggested in previous threads.

Cheers.

bugeater87

Ok - been through the forums a couple times and basically found and verified the following:

Verifyed http.conf has mod_rewrite
Allowoverride All set for root in httpd.conf
Setting "RewriteRule ^.*$ %1/http.php/$1 [L]" or "RewriteRule ^.*$ %1/http.php/ [L]" returns bad URL in api/.htaccess

Results so far
Login attempt via Azure now returns to home without logging in.
Login attempt via LDAP returns access denied

Any other items I might be missing?

KevinTheJedi

bugeater87

Clear all cache, cookies, and sessions and retest. Or try an incognito/private window or different browser to retest.

Cheers.

bugeater87

Yes - i've tested in incognito/private windows in both edge and chrome with same results.

KevinTheJedi

bugeater87

What do the Agent's/User's backend look like in the database? Users backend should be on user_account table and Agent's should be on staff table.

Cheers.

bugeater87

For users, it is ldap.client.

for staff, it is set blank (not null). In the admin console it is set to any.

I can login via ldap to the agent portal. But OATH goes back to home screen and does not login.

KevinTheJedi

bugeater87

Okay the users with the ldap.client backend will need to be updated. See here:

https://forum.osticket.com/d/101553-ldap-not-enter-whit-user/15

For OAuth2 issues, others have had to do something with their web.config to get it working I can’t remember what exactly. You can search other threads on this.

Cheers.

bugeater87

I was able to get LDAP to work by downgrading PHP to 8.0 from 8.1.

OAUTH still doesn't work. Just returns to main screen after going through login from AzureAD. I've tried different options for User Identifier on the OAUTH config page. Username and Userprincipalname do not work. Not sure if this is a problem causing the mismatch or not, but thought it might be worth checking.

thanks

KevinTheJedi

bugeater87

You can check your IIS logs to see if the URL is being blocked, check your web.config to make sure the URL Rewriting is configured properly, etc.

Cheers.

bugeater87

I'm using Apache on Windows not IIS
Apache/2.4.53 (Win64) OpenSSL/1.1.1o PHP/8.0.25

KevinTheJedi

bugeater87

My reply still stands but instead check Apache error logs.

Cheers.

bugeater87

Loglevel is set to error in httpd.conf. Nothing shows in the error log. Below is from the access log.

Here is the field mapping settings on the OATH setup

KevinTheJedi

bugeater87

Upgrade to v1.17.1, install the latest OAuth2 plugin, and retest.

Cheers.

bugeater87

Upgraded to v1.17.1, re-installed OAuth2 and still get the same results.

At this point we are live and using LDAP so we are OK for now. I'll check back in a couple months to see about the next updated to see if there is any resolution to move to OAuth2.

KevinTheJedi

bugeater87

v1.17.2. was released last week along with a new build of the plugin. You can try with those and see. I'm unable to replicate the issue so I'm unsure what's going on in your case. I'm able to authenticate as users and agents to MS using OAuth2.

Cheers.

MarkHoward

bugeater87
Hello,
Glad you have it working. How are you authenticating to fetch messages? My understanding was that OAuth was required to do so.
Thank you