AD Bind - Config Profile or Policy?

I use a script that runs dsconfigad as it gives you some controls around timing and making sure the machine is in a known good state before binding. Binding isn't so bad if you add some guard rails. An extension attribute that does some checks to make sure your AD binding is working correct can help a lot. Build that in a way where you can create a smart group of machines that might need some attention. Things that I check for in my EA include:
dsconfigad -show to check the current binding config
dscl /Search read /Computers/"${adComputerName}" RecordName to see if the machine can query it's own computer object in AD.
security find-generic-password to look for the computer's AD password in the system keychain.

Along with Jamf Connect, you might take a look at xcreds and pay attention to what Microsoft is doing with platform SSO.

The best option is don't domain bind. Domain Binding is done with a Policy, not a Configuration Profile.

If you need to domain bind Macs, you have to set up some things in JAMF before you can build the policy. Once the Macs are domain bound you can use a Configuration Profile to deliver certificates. I suggest looking in to JAMFs ADCS Connector if you are needing ADCS certificates. 

https://docs.jamf.com/10.33.0/jamf-pro/administrator-guide/Directory_Bindings.html

https://docs.jamf.com/technical-papers/jamf-pro/integrating-ad-cs/10.30.0/Installing_the_Jamf_AD_CS_Connector.html

Thanks @AJPinto  I have the ADCS set up for my cloud instance I'm moving to in March.  I'm trying to find a short term solution for my on-prem servers.   Someone set it up with a configuration profile, yet it fails to apply to about half of them stating a credentials issue - and it can't be that because it applies to others properly to others.

If I run a policy - is it ongoing or once per?   I'm wondering your thoughts if I create a policy and apply it to all computers and a few days later remove the cofiguration profile.  I was told that unbinds the device when you remove it.

I belt and suspendered it with a binding action in the prestage, along with policies calling dsconfigad should the prestage binding fail.

In the past I have used config profiles, but had problems with them triggering a rebind if you made any changes, even when applied to new devices only. This was enough years ago that it may have been due to a since resolved bug.

I still favor dsconfigad for the greater flexibility offered, but it does require some knowledge of AD and comfort with the command line to use. Having a bind action on the prestage is probably the easiest method.

We're moving off this to Jamf Connect, however I have to do it for at least the next quarter.

The org runs  hybrid setup with on-prem AD syncing to Azure.

Can't bind in prestage because it can't reach the controllers since it's off-net.

We have situations where the bind policy fails on the first  runs - because the device hasn't yet connected to the VPN.  Once per computer with rerun on failure.  

Configuration profile throws errors because it can't bind with the system off-net.

I'm over thinking this and can't find a way to effectively bind the system.

I appreciate any input.

I would bind using a script. Then you can apply some logic in the script before you bind to make sure you can query a domain controller.

Also, binding isn't great if your Macs frequently are unable to communicate with your AD domain. An always connected VPN would be helpful.

Stall your binding attempt until the system is on an acceptable part of the network, such as by taking it out of the prestage and limiting the scope of a successor policy or config profile to an appropriate network segment. This may mean forcing an additional inventory update or restart before binding kicks in.