Multiple users being created for the same AD account

Hey,

after setting up external authentication to active directory multiple user accounts are being created depending on the username format used to sign into ManageIQ.

I have managed to create 3 different accounts in ManageIQ for the same user by using the following format for logins:

  • domain\username
  • username@domain OR username
  • User.Name@domain

All of the users created in manageIQ are identical except for the username field. This is causing us problems since only one user is the owner of a resourse and loging in with another format means you loose access to those resources.

Is there any way to specify which ldap/ad field ManageIQ should use for the username?r

Best regards,
Žiga

Hey Žiga,

There are multiple ways to configure external authentication with ManageIQ. ManageIQ attempts to standardize the username format as UPN, username@domain, when possible. This requires the Identity Provider to supply the domain portion. One condition that can cause what you are observing is if you have attempted different forms of external auth. There are others.

Please see these blog posts for help debugging your particular issue.
ManageIQ Authentication Overview
[ Troubleshooting ManageIQ Authentication]ManageIQ - Troubleshooting ManageIQ Authentication)

There is a section in those blog posts that outline what to provide when reporting issues. If you are unable to resolve your issue after following the information please provide all the data described

Best regards,
JoeV

Hi Joe!

Thank you for the links. I did indeed follow the guide that is also mentioned in the blog to enable and configure direct external authentication to Active Directory: ManageIQ

/var/www/miq/vmdb/bin/rails runner 'puts Settings.authentication’

#<Config::Options basedn=nil, bind_dn=nil, bind_pwd=nil, bind_timeout=30, debug=false, follow_referrals=false, get_direct_groups=true, group_memberships_max_depth=2, group_attribute="memberof", ldaphost=[], ldapport="389", mode="httpd", max_failed_login_attempts=3, locked_account_timeout="2.minutes", search_timeout=30, user_suffix=nil, user_type="userprincipalname", amazon_key="********", amazon_secret="********", ldap_role=false, amazon_role=false, httpd_role=true, user_proxies=[#<Config::Options>], provider_type="none", local_login_disabled=false, saml_enabled=false, oidc_enabled=false, sso_enabled=false>

/var/www/miq/vmdb/bin/rails runner 'puts MiqGroup.pluck(:description)``` does return valid AD groups that users are members of. I did check with ´id username

/var/www/miq/vmdb/bin/rails runner 'puts User.pluck(:userid) returns this (among others):

username@example.com 
user.name@example.com
examplecom\username@example.com

So entering the username domain\username in the form produces a examplecom\username@example.com in manageIQ
username@domain OR username -> username@example.com
User.Name@domain -> user.name@example.com

The email in all of the cases is user.name@example.com where givenname = user, surname= name

/etc/sssd/sssd.conf

[sssd]
domains = example.com
config_file_version = 2
services = nss, pam, ifp
default_domain_suffix = example.com

[nss]
homedir_substring = /home

[pam]
default_domain_suffix = example.com

[ifp]
allowed_uids = apache, root
user_attributes = +mail, +givenname, +sn, +displayname, +domainname

[domain/src.si]
ad_domain = example.com
krb5_realm = EXAMPLE.COM
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
dyndns_update = true
ad_gpo_ignore_unreadable = True
ad_gpo_map_permit = +httpd-auth
ldap_user_extra_attrs = mail, givenname, sn, displayname, domainname

dbus_send does provide the same output as the examples given.

Do you want me to provide any log files in specific? I would like to avoid uploading a ~300MB zip file if possible.

The authentication works and all three users are placed in correct groups so there’s no problem there.

You are mixing three different formants which likely return three different results from you Identity Provider. You should use UPN (username@domain) or simple username.

If you do the following three dbus-send commands I suspect you will get three different "sn"s

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:username@domain array:string:mail,givenname,sn,displayname,domainname

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:User.Name@domain array:string:mail,givenname,sn,displayname,domainname

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:domain\username array:string:mail,givenname,sn,displayname,domainname

If these three examples return different “sn” and “domainname” records they will appear as different users to ManageIQ.

I suggest you manually delete the domain\username and User.Name@domain records in ManageIQ and then use only use UPN (username@domain) or simple username when logging in.

They actually don’t return a different result. Here’s the output:

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:User.Name@domain array:string:mail,givenname,sn,displayname,domainname

method return time=1611241765.165459 sender=:1.75 -> destination=:1.1107 serial=143 
reply_serial=2
   array [
      dict entry(
         string "mail"
         variant             array [
               string "User.Name@domain"
            ]
      )
      dict entry(
         string "givenname"
         variant             array [
               string "User"
            ]
      )
      dict entry(
         string "sn"
         variant             array [
               string "Name"
            ]
      )
      dict entry(
         string "displayname"
         variant             array [
               string "User Name"
            ]
      )
      dict entry(
         string "domainname"
         variant             array [
               string "domain"
            ]
      )
   ]

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:username@domain array:string:mail,givenname,sn,displayname,domainname

method return time=1611241930.237534 sender=:1.75 -> destination=:1.1109 serial=145                 
reply_serial=2
   array [
      dict entry(
         string "mail"
         variant             array [
               string "User.Name@domain"
            ]
      )
      dict entry(
         string "givenname"
         variant             array [
               string "User"
            ]
      )
      dict entry(
         string "sn"
         variant             array [
               string "Name"
            ]
      )
      dict entry(
         string "displayname"
         variant             array [
               string "User Name"
            ]
      )
      dict entry(
         string "domainname"
         variant             array [
               string "domain"
            ]
      )
   ]

dbus-send --print-reply --system --dest=org.freedesktop.sssd.infopipe /org/freedesktop/sssd/infopipe org.freedesktop.sssd.infopipe.GetUserAttr string:domain\username array:string:mail,givenname,sn,displayname,domainname

The same thing so no point in pasting it here. I checked with diff command so there really is no difference, which makes sense since they are all the attributes of the same object in AD. 

While that is a solution, it’s not a good one. Even I will probably forget or make a mistake at one point or another and use a different format. I will at least know why I don’t see any of my systems, but our users won’t. I think we both can imagine this will create a lot of support tickets, which are just going to take up unnecessary time.