Kerberos is a networking protocol and is the default protocol used by Windows for authentication when joining a Windows domain to establish trust. I don't think you can run a Windows Domain without also running Kerberos on all of the connected machines. See RFC 3244 and RFC 4757 to learn more about the Microsoft specifications and its uses. Kerberos can also be used on Unix, Linux and other platforms, including iOs.
To address your 1st question, it is VERY insecure and not at all recommended to send login
using https://firstname.lastname@example.org&pw=Password1234!! Doing that defeats all of the security benefits of implementing SSO. You're exposing both your usernames and passwords for anyone to hack.
What you may not be aware of is that Salesforce does not retain, doesn't care about, and doesn't want the username or password during delegated authorization. It passes what is receives during log-in to your org via the web service you've configured for authentication. If your service returns "success", it authenticates your user and allows them to log-in to your org. Otherwise, it simply denies the request. It doesn't retain anything related to the transaction. All records are kept in your Salesforce org, not in the idP part of Salesforce.
For your other question, if your users are using Windows machines that are on your network, they should be authenticating with your network using Kerberos. The mere act of logging into to your Domain Servers, should allow them to have an active token that can be sent from their machine to Salesforce. Salesforce can then send it via the web service to your server to validate them. Even when they're not logged in to your org's Domain, I'd expect them to have a refresh token from your Domain servers that Kerberos would send to Salesforce (am not knowledgeable on all the details related to Kerberos, so am "improvising" a bit on the refresh token).
Although it's not in a delegated SSO context, I think you'll find the following article's references to Kerberos helpful as part of a Salesforce SSO AD implementation:
Configure SSO to Salesforce Using Microsoft Active Directory Federation Services as the Identity Provider
In Response to comments...
I recommend you read relevant parts of the Single Sign-On Implementation Guide and go to "Sample Delegated Authentication Implementations". Also download the sample code for .NET. Then, review Sample 2 on that page.
When it comes to communities, this kind of Delegated Authentication configuration is not intended to work with Communities. Communities require MyDomain to be enabled while Delegated Authentication does not. More importantly, you cannot log in to a Community from login.saelsforce.com. Each Community has its own login page. You'll want to explore other options such as using Social Sign On instead.
Salesforce Authentication via Delegated Authentication is often a very complex subject and not easy to discuss in this venue. I recommend you explore the vast amount of documentation available to you and try to post new questions of limited scope one at a time as you find you have them.
Other resources I think you may find helpful would include: