The short is answer no. However to elaborate this a bit more:

Kerberos is an older Protocol which only works "behind the firewall", so usually in a local LAN/WAN/VPN with domain-joined PCs. 

For requirements like

  • access from outside the LAN/VPN,
  • access from Phones/Tablets or other non-domain joined Devices
  • no direct network connection between the Atlassian Application and the Domain DCs

it does not really work via Kerberos and a SAML based solution is necessary.

To use SAML in an Active Directory you will have to have the Active Directory Federation Services (AD FS) role installed on a Server/DC somewhere in your AD. And in todays world most companies actually have this already as federation to Office 365/Salesforce and other popular cloud services already require this.

So many customers would end up in a scenario where the would require a Kerberos Konfiguration to authenticate domain-joined LAN connected machines & then an additional SAML configuration to AD FS to authenticate everything else. That means:

  • Two configurations (even if it's in the same Plugin) to maintain,
  • Two different potential for policies; Access policies that can be enforced in ADFS, can't be via direct Kerberos
  • Knowledge to troubleshoot two different Protocols

However, AD FS has a function called Integrated Windows authentication and it's turned on by default. In this case AD FS authenticates domain-joined devices via Kerberos and everyone else via Form-based (i.e. Username/Password) authentication. 
This enables AD FS to enforce configured policies (like 2nd Factor/Smartcard/Certificate authentication for all or certain groups like admins) across all Devices, domain joined or not - internal or external.

Conclusion: With AD FS you can get the benefits of centralised policies, ease of Kerberos and flexibility of SAML altogether. Only requiring once Protocol (SAML) towards your Atlassian Application.