Quinn, We're trying to minimize updates chasing the key name. The only OS version with the kTCCServiceEndpointSecurityClient key is 13.0.0? All others will use kTCCServiceSystemPolicyAllFiles? Is that correct -- at least for the near future? Thanks a lot, Jim

So it appears I was going about it the wrong way. Going through NSURLSession does the job.

A simple NSURLSession dataTask to the IIS machine with AD accounts worked fine. It was pretty cool. That means my setup was okay. I guess I was going about it entirely the wrong way?

My problem was that I messed up the SSO policy plist I was sending down from SimpleMDM. Copying the sample plist verbatim but changing the domain/host got it basically working.

Thanks -- I found my mistake.

Hi Quinn, Since I'm in a daemon and I need my own keychain file separated from the rest of the world I'm targeting a traditional file-based keychain. I tried adding items to my keychain using the dictionary key that you specified elsewhere to set the target keychain and that worked. The keychain item is actually where I want it when I open up the keychain file in Keychain Access. However, when I search for it using the SecItem APIs I don't get it returned to me. I would ALSO like the ability to have a memory based keychain eventually, but that is secondary. Thanks for any help. Jim

Solved the problem with no users showing up. Solved the problem with the policy. Thanks to the tech support at SimpleMDM for that. I'm unfamiliar with what sort of URL to initialize the ASAuthorizationSingleSignOnProvider with, though. [authProvider canPerformAuthorization] returns false and I'm pretty sure it is because I don't have the policy right yet OR the URL is wrong.

I'm enrolling a Parallels VM into SimpleMDM and trying to push down the Single Sign-On configuration to it as a custom configuration. So far I haven't seen the policy come down, though I've pushed down System Update successfully.

I got things working with dispatch and xpc, so this question isn't really relevant any longer for me. Glib has internal tests for the main thread and that made things congested. It turned out to be easier for the moment to simply avoid dispatch_main and let glib have the main thread.

It is exceedingly unlikely they're going to change the volume format at this point.

Thanks for the responses. I am looking at making glib use dispatch for event handling as potentially a performance enhancement. I've downloaded the dispatch source and looked through it a good bit and that has been somewhat helpful. Some really gnarly macros live in there. You've given me an idea for a path around the immediate problem. I THOUGHT I'd tried it when I ran into the problem initially, but I'll need to verify.

On unix the process parses the command line utils and then based on them it daemonizes so that the command line util can terminate and the daemon hangs around indefinitely. What I'm doing for macOS is have the command line util parse the params and then XPC them to a mach service registered with launchd. XPC and dispatch are conflicting with the shared unix glib code for event loops and signal handling. I'm working on making glib use dispatch and dispatch_io with the side benefit of hopefully being more efficient, but I'm wondering if all of this is necessary since the immediate reason to do this is to avoid the daemon call. Exactly how this will work in the finished product is unknown.

SCDynamicStoreCopyConsoleUser will tell you if someone is logged in and what the user information is. You can set up user agents to run on user login and signal you or you can look at the security log device for login events.

It is an apple registered domain according to whois. Secure boot makes sense.

Perhaps as a workaround you could use Parallels?Catalina has been okay. Issues I've had are:my video card rebooting seemingly randomly a few times a dayI have a once a month hard lock up that I didn't have on my older hardware and OSI usually stay on 10.x.6 until 10.x+1.5 comes out, but new hardware didn't allow me that luxury this cycle, so I feel your pain.