The short is answer no. However to elaborate on 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 today's world, most companies actually have this already as a federation to Office 365/Salesforce and other popular cloud services already require this.

So many customers would end up in a scenario where they 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 potentials 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 one Protocol (SAML) towards your Atlassian Application.