dsconfigad --show not working in Monterey

Sounds like you must be using an IT managed Mac. You should inquire with your IT department. That being said, I am a MacSysadmin / Engineer for my employer and can shed some light on what's going on.

The "dsconfigad" command uses the macOS built-in Active Directory plugin. However, Apple Enterprise Connect does not use the macOS AD plugin. The Mac doesn't need to be bound to AD for Enterprise Connect to function. Enterprise Connect talks directly to your Active Directory and Kerberos authentication bypassing the older macOS AD Plugin. You can still bind a Mac to AD but the whole point of Enterprise Connect was to avoid doing so.

When you bind a Mac to AD using the dsconfigad command and login with an AD account, a mobile user account is created. The passwords easily get out of sync when you change your password and the FileVault cached copy of the password may be the previous password. The keychain will prompt the user extensively and the user needs to know to enter their previous password to unlock the keychain and allow the keychain password to be updated. Despite extensive user training this behavior caused no end of trouble for help desks as it was frequently occurring every time a users password expired or was reset. To solve the problem, Apple Enterprise offered IT corporate departments the option to not bind the Macs to AD and use local accounts along with their new Enterprise Connect software which will detect when the password is changed and allow the user to change the password and sync the password on the Mac, in the keychain, and in FileVault.

When Apple first made Enterprise Connect available you had to be a corporate business and not an educational institution to obtain it. The tool was written by internal Apple employees in the Enterprise Support division. It was not included with the operating system. Although Enterprise Connect wasn't necessarily individually licensed, you had to pay for an in person site survey and evaluation including travel expenses for Apple Engineers to gain access to the software. Apple wanted to ensure that Enterprise Connect would work in your environment and because many AD environments were configured outside of Microsoft best practices that is why they wanted a site survey and onboarding process to ensure things would work properly. That resulted in many Apple customers without the financial means or those in the Education market to seek an alternative solution.

There was a couple of early Python based open source community solutions, whose names now escape me, but have since been EOL retired and replaced by the open source Swift language, NoMAD (No More Active Directory) tool. NoMAD works very similarly to Enterprise Connect. JAMF one of the leading Mobile Device Management server providers bought out the company behind NoMAD and they now sell JAMF Connect which is a commercial version of NoMAD that supports many modern Identity Providers such as OKTA, Ping, AzureAD, JumpCloud, etc. for cloud authentication. The original NoMAD, which supports on-prem Active Directory servers is still open source and free. But if you require cloud authentication, I don't know of any free solutions at this time. JAMF Connect is licensed per user and it's typically deployed with the JAMF MDM products.

Apple has started building Enterprise Connect functionality into macOS as an option for IT departments to utilize. The Kerberos SSO extension is intended to replace Enterprise Connect. It does require a complex configuration that really should be deployed via an MDM server and it is not as full featured as JAMF Connect nor NoMAD. It could be deployed by Microsoft Intune which does support Apple MDM Configuration Profile payload deployment functionality and works with Apple Business / Education Manager.

I have a fleet of Macs that I manage at work using NoMAD and it's been rock solid. We have a Configuration Profile to configure it's behavior and it runs as a LaunchAgent on the users Macs. We may be transitioning to JAMF Connect to provide PING Federated and AzureAD authentication in the future. I've tested the Kerberos SSO plugin as an alternative to NoMAD / Apple Enterprise Connect and it works but I find I like NoMAD / JAMF Connect better. That is just my personal opinion, there are many factors when considering which solution to choose. The Kerberos SSO plugin is improving since Big Sur. It may become the right choice in future. Microsoft also has an SSO plugin in beta that is coming along nicely as well for those who might prefer a Microsoft solution.

Most problems anyone would encounter would be issues with DNS or AD configuration at the server / network level.

You'll need to be logged into your company network on the LAN / WiFi or over VPN. If you are logged in you will have a Kerberos ticket. You can run a "klist" command in Terminal to list any Kerberos tickets indicating that EC logged into Active Directory. You can run "kinit user@domain.com" where domain.com = your AD FQDN (Fully Qualified Domain Name), you should see a password prompt and after you login run "klist" again to see your Kerberos tickets. You can destroy the tickets with "kdestroy". You can check for SRV records as this is how EC finds your Active Directory, "dig +short -t SRV _ldap._tcp.company.com" where company.com = your FQDN (Fully Qualified Domain Name). If you are logged on with a Kerberos ticket you should be able to run an LDAP query against Active Directory (providing your account has that privilege), "ldapsearch -LLL -Q -H ldap://server.company.com -s base defaultNamingContext".

You can also determine if EC is running:

ps auxww | grep Enterprise | grep -v grep

You can kill the EC process and it should autostart if it's configured in Launchd to do so, which it should be:

kill -9 XXXX YYYY

Where XXXX and YYYY are the process id's (PID) obtained from the previous "ps" command.

You may require local admin privileges to kill a running process outside of your own user processes.

If EC doesn't autostart you can start it manually in /Applications, Spotlight, LaunchPad, etc.

Enterprise Connect can be used with SmartCards, etc. If you have authentication problems you will need to call your Help Desk as EC is managed by your IT Department along with Active Directory and your login account, etc. Your IT department will know best because this is not a tool you can likely fix yourself.

You should be able to initiate an LDAP query to the Active Directory controller from within your C application, if you can't connect you are not on the company network. You can also shell out and run "klist" to see if the user has authenticated to AD. If the user is not signed into Kerberos via EC the response from "klist" will be "klist: Cache not found: API:574AA836-B1FB-4E80-9EA4-5C9961CC99EB" or something similar you only need to know the "klist: Cache not found" portion.

You might need a certificate from the AD Team that will allow you to connect via LDAP to the AD server. I had to do that to get the Java based MDM JAMF Pro software to connect to LDAP so we could enable AD based sign-on to the JAMF Pro web application.