Kerberos authentication fails if realm is not FQDN

Our Active Directory domain is historically named sa.c, and consequently the AD provides a Kerberos realm named SA.C. This name ostensibly does not play well with GitLab through OmniAuth: an attempt to authenticate ends up in a 422 error page showing the error Sign-in failed because email is invalid, notification_email is invalid. There is a record in GitLab's application.log created at the same time:

(OAuth) Error saving user: ["Email is invalid", "Notification email is invalid"] 

My conjecture is that the Kerberos ID, which has the form user@SA.C, is somehow checked for validity as if it was an email address during account creation, and the code rejects this string in the email and notification_email of the new user record. I came to this assumption when I tried to add user@SA.C as one of my alternative e-mail addresses on the Account page, and got the error that read the same: "Email is invalid".

Below is the relevant snippet of configuration:

gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = true
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_providers'] = [
  {
    "name" => "kerberos",
    "keytab" => "/etc/gitlab.keytab"
  }
]

Added 150923: Confirmed the source of the problem is email validation by temporarily disabling it in app/models/user.rb:

--- user.rb.bak 2015-09-23 15:33:41.153046701 -0700
+++ user.rb     2015-09-23 15:34:32.044741054 -0700
@@ -144,4 +144,4 @@
   # duplicate that here as the validation framework will have duplicate errors in the event of a failure.
-  validates :email, presence: true, email: { strict_mode: true }
+  validates :email, presence: true
-  validates :notification_email, presence: true, email: { strict_mode: true }
+  validates :notification_email, presence: true
   validates :public_email, presence: true, email: { strict_mode: true }, allow_blank: true, uniqueness: true

With this change, a new user is created just fine with a lowercased version of Kerb ID as their email, user@sa.c.

I have no idea what a permanent fix would look like. It seems that this ball is in your court now.

@kkm the reason we validate the FQDN of the email is so that emails can be sent to this address. I assume that, in your case, if GitLab tries to send an email to user@sa.c it will fail, because that is not a real email address, right?

Sending emails is a key part of GitLab's functionality.

No, why, it is a perfectly valid and working e-mail address (internal-only though, of course). It is also valid per RFC5322 (see addr-spec in sec 5.3.1). The Rails email validation library is simply over-vigilant. From reading its code, it requires at least 2 characters after the last dot in the address.

Even the last dot part is unnecessary. sa.c may be interpreted as sa.c. or sa.c.acme.com., i. e. relative to the default domain. Similarly, user@mail will be treated as user@mail.acme.com by a standard=compliant mail software (postfix is ok indeed). Finally, the domain may be remapped in sendmail or postfix entirely, so the email is going to e. g. user@anywhereyouwant.com instead.

Many of these options would be rejected by the email checker. Maybe adding a config option to GitLab to relax e-mail checking in a particular enterprise installation would cover all bases? What do you think? Certainly I do not want to patch every new update of GitLab EE, so our "solution" is indeed not permanent; it is rather only an ugly temporary workaround.

mentioned in commit 6fe38380