Search Results :


What is Kerberos?

Kerberos is a cryptography-based authentication protocol that guards access to applications. This protocol is designed to provide secure authentication over an insecure network. The key idea behind Kerberos is to authenticate users while preventing passwords from being sent over the internet.

Secure Authentication

Kerberos uses a strong cryptography to authenticate users, ensuring secure access to systems and resources.

Mutual Authentication

Kerberos verifies the identity of both the client and the server, ensuring the communication is secured and preventing impersonation attacks.

Cross Platform Compatibility

Kerberos is a widely adopted SSO protocol, supported by various operating systems and applications.

What We Offer

Kerberos/NTLM Authentication SSO into intranet


Single Sign On into intranet using Kerberos/NTLM which works on all the major OS like Windows, Linux, Ubuntu, CentOS, etc.

Passwordless authentication using Kerberos/NTLM SSO

Passwordless Login

Kerberos is a passwordless computer network security authentication protocol. Many organizations utilize it for SSO.

Kerberos documentation for single sign on

Vast Documentation

The detailed steps that will walk you through all the configurations that need to be done on both your server and your AD.

Kerberos SSO setup over a screen share call

End to End Setup

Get help from our developers to setup your Kerberos/NTLM SSO through an interactive screen share session.

Kerberos Pricing

One time Kerberos setup

One time Kerberos setup and one year of free support


Contact Us

We are happy to help, feel free to contact us

Hi, how can we help?

Have questions or need any support with Kerberos setup? We've got you covered.

"Thank you for your response. We will get back to you soon."

"Something went wrong. Please submit your query again."

Top Questions about our Kerberos/NTLM SSO

Why am I getting a prompt to enter my credentials?

This happens when the NTLM protocol is used for Authentication instead of Kerberos.
This may occur due to multiple reasons:

  • Check if you are using a domain joined machine to access the website.
  • Make sure the time is synchronized between the LDAP server and webserver.
  • Confirm if your browser settings and Internet options are configured for Kerberos SSO.
  • If you are still facing this issue, feel free to contact us.

Can I use an existing LDAP user as a Kerberos Service principal?

Yes, you can use an existing LDAP user as a Kerberos service principal. However, this user must have a password set to never expire. Kindly make sure this account is not used by any user as the application uses this account as the Kerberos service principal and the corresponding keytab to obtain a kerberos ticket.

What is a "Kerberos client", "Kerberos server", and "application server"?

All authentication in Kerberos occurs between clients and servers. Therefore, any entity that receives a service ticket for a Kerberos service is referred to as a "Kerberos client" in Kerberos terminology. Users are often considered clients, but any principal might be one.
The Key Distribution Center, or KDC for short, is typically referred to as a "Kerberos server". Both the Authentication Service (AS) and the Ticket Granting Service (TGS) are implemented by the KDC. Every password connected to every principal is stored in the KDC. Because of this, it is essential that the KDC be as safe as feasible.
The phrase "application server" often refers to Kerberized software that clients use to interact while authenticating using Kerberos tickets. An example of an application server is the Kerberos telnet daemon.

How are realms named? Do they really have to be uppercase?

In theory, the realm name is arbitrary. You can name your realms whatever you want.
In practice a Kerberos realm is named by uppercasing the DNS domain name associated with the hosts in the to-be named realm. For example if your hosts are all in the "" domain, you might call your Kerberos realm as "EXAMPLE.COM".
If you wish to have two Kerberos realms in the DNS domain "" for Human Resource and Sales, you might create the Kerberos realms as "HR.MINIORANGE.COM" and "SALES.MINIORANGE.COM"
The convention to use uppercase for realms names is to easily distinguish between DNS domain names (which are actually case-insensitive) and kerberos realms.
The recent revisions to the Kerberos standard have specified that uppercase realm names are preferred and lowercase realm names have been deprecated.

What programs/files need to go on each application server?

On each application server, you'll need to put:

  • A Kerberos configuration file (/etc/krb5.conf).
  • The Kerberos application server daemons (telnetd, rlogind, ftpd, etc).
  • At least one encryption key (usually stored in /etc/krb5.keytab).

The portion that is most important is the encryption key; it must be sent to the application server host in a safe manner. Usually, the host principal (host/ uses this key. It should be noted that the MIT admin client kadmin encrypts every transfer between it and the admin server, making it safe to use ktadd from within kadmin as long as you're not transmitting your admin password over the network in clear text.
If you intend to have interactive user logins on your application servers, you'll probably also want to install the Kerberos client binaries on each one.

What is GSSAPI?

GSSAPI is an acronym; it stands for Generic Security Services Application Programming Interface.
Client-server authentication is handled using the GSSAPI, a general-purpose API. The reasoning for it is because each security system has its own API, and because security APIs differ so much, it takes a lot of work to add various security systems to apps. The generic API could be written to by application providers, and it would be compatible with a wide range of security systems if there were a common API.

What is cross-realm authentication?

Any Kerberos principal can establish an authentication connection with another principal inside the same Kerberos realm. However, a Kerberos realm can also be set up to allow principals from different realms to authenticate with one another. This is called cross-realm authentication.
This is accomplished by having the KDCs in the two realms share a unique cross-realm secret, which is used to validate the identification of principals when they cross the realm border.

How do I change the master key?

In Kerberos 5 you can not change the master key.
You have the option to modify the master key using the kadmin. The master key, however, is used to encrypt every database entry and is most likely also kept in a stash file (depending on your site). The stash file or all of the database records won't be updated if the master key is changed using kadmin.
To change the master key, Kerberos 4 offered a command, and it carried out the necessary actions. For Kerberos 5, no one has (yet) implemented this capability.

Hello there!

Need Help? We are right here!

Contact miniOrange Support

Thanks for your inquiry.

If you dont hear from us within 24 hours, please feel free to send a follow up email to