search

Adldap2 / Adldap2-Laravel

LDAP Authentication & Management for Laravel
MIT License
910 stars 184 forks source link

Scheduled Task - Can't contact LDAP server #794

Open nspaul opened 4 years ago

nspaul commented 4 years ago

Description:

I know this isn't a macOS support forum, but hear me out... it's very specific to Adldap2-Laravel! I upgraded to Catalina today, and I have a Laravel app that uses Adldap2-Laravel, and my function works great when I manually run the Command from the cli. I also have a Scheduled Task as part of this Laravel application. This task simply runs the Command I mentioned earlier, and the task was running on its schedule just fine before the upgrade. After the upgrade, this was the first app I checked. Running via cli is successful, and it does LDAP queries as you'd expect. However, when the Scheduled Task runs the Command, those same Adldap2-Laravel function calls fail. I am seeing this in my laravel log: [2019-10-14 15:00:00] local.WARNING: LDAP (ldaps://domaincontroller.core.gtri.org:3269) - Connection: default - Operation: Failed - Username: username@domain.org - Reason: Can't contact LDAP server

The odd part about this is that it works when run manually. Does anyone know if there is some fundamental difference between Laravel running a controller's method as part of a Command on the cli, versus running it as part of a Scheduled Task? Does the Adldap2-Laravel package handle these two scenarios in some different way that would break down the communication to my AD server?

stevebauman commented 4 years ago

Hi @nspaul,

The difference here seems to be the account that the command is running under. When you specifically run the command yourself, it's using your accounts permissions. When you run the command as a scheduled task it's running under the systems account.

It seems maybe some privileges got changed with the system account that is running your scheduled task where it cannot connect to network resources? I know this is an issue with Windows, as I have created scheduled tasks in the past that to do not run successfully if the account running them does not have permission to connect to network resources (such as shared drives).

I don't know enough about MacOS unfortunately - I'm primarily developing on Windows. ☹️

stevebauman commented 4 years ago

Oh, and to answer your question, there is no difference to how the command is executed with Adldap2-Laravel. It is executed identically no matter where you execute it from, such as calling it from command line, calling it via the Artisan facade, or even executing it manually via a controller method.

nspaul commented 4 years ago

I think this line of thinking is correct. There is some recent discussion on Twitter (here: https://twitter.com/DaveWoodX/status/1184235412509941761) about Catalina cron jobs not being about to touch certain files/folders in Catalina, and it is because of the new security measures put in place. The fix for this file/folder access issue is to drag /usr/sbin/cron into the Full Disk Access area in System Preferences.

However, I don't yet know the equivalent of this for network access, if there even is one. I wonder if Catalina is blocking the cron job from making network requests, specifically LDAP requests. I am posting this here in case someone else is reading this and has come across something similar. Meanwhile I am still hunting down a fix myself, and if I find one, I will report back.