First, an explanation of what GSSAPI ServiceHost is.

When connecting via Kerberos, a service ticket must be obtained from the Kerberos Ticket Granting Service in order to authenticate.  The principal name of the service is required (along with the TGT - Ticket Granting Ticket) in order to obtain the service ticket. The service principal name consists of two parts: (1) The service name and (2) The service host.  For example, for a mongod running on host example.com, the principal name would be "mongodb/example.com".

Usually, the service host can be determined from the hostname that the application is connecting to.  However, there are cases in which an application may want to connect to "localhost".  This is required for example when creating the initial user, or in the case of LDAP Authorization, creating the initial role. This use case relies on the localhost exception which as of MongoDB 3.4 "allows users authorizing via LDAP to create a role inside of MongoDB that maps to a role defined in LDAP"

When creating an initial user, service host is not required because there is no need to authenticate.  No users exist yet!  But it is in the case of LDAP Authorization that things get interesting.

In an LDAP Authorization setup, no users actually exist in MongoDB.  The users exist externally to MongoDB.  For example, in a Kerberos + LDAP Authorization setup, the user would authenticate to MongoDB via Kerberos.  LDAP is then used for authorization by asking the LDAP server which LDAP groups the user belongs to and then mapping those groups to custom roles in MongoDB which would then inherit built-in roles or privileges.

When setting up an LDAP Authorization deployment, no custom roles exist yet for LDAP groups to map onto.  Therefore, none of the users have privileges yet.  MongoDB allows you to get round this by allowing you to create the initial custom role via the localhost exception.  However, in order to do this, you MUST be authenticated as a user who belongs to an LDAP group that maps onto the initial role that you are creating.

It is because you must both be authenticated and connected to localhost in order to create the initial role that ServiceHost support is required.  By ServiceHost support, I mean that you can tell the driver to use a service host different than the hostname being connected to for the purposes of determining the service principal name.  Without it, GSSAPI would be trying to use "localhost" as the service host which would lead to an incorrect service principal name (for example, "mongodb/localhost").

For an example of where this is implemented in the mgo driver see: https://github.com/globalsign/mgo/blob/113d3961e7311526535a1ef7042196563d442761/session.go#L520

There is an already a ticket for this for our official Go driver: GODRIVER-698