Please follow https://fedorahosted.org/sssd/wiki/Troubleshooting and provide SSSD logs.

The empty 'passwd' and 'group' lines in /etc/nsswitch.conf are a bit odd. Does it help to add 'files sss' here?

(In reply to Sumit Bose from comment #3)
> The empty 'passwd' and 'group' lines in /etc/nsswitch.conf are a bit odd.
> Does it help to add 'files sss' here?

You are right. I got this nsswitch this way:

~~~
# mv /etc/nsswitch.conf{,.bak}
# dnf reinstall glibc

... snip ...


# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:     sss files
shadow:     files sss
group:      sss files

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   nisplus sss

publickey:  nisplus

automount:  files nisplus
aliases:    files nisplus


# authconfig --updateall


# cat /etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:    
shadow:    
group:     

#hosts:     db files nisplus nis dns
hosts:      files nis dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files nis sss

publickey:  nisplus

automount:  files nis sss
aliases:    files nisplus
~~~

But neither the original glibc bersion nor the one after authconfig call helps ...

I should probably mention version of glibc and authconfig as well:

$ rpm -q glibc
glibc-2.25.90-1.fc27.x86_64
glibc-2.25.90-1.fc27.i686

$ rpm -q authconfig
authconfig-7.0.0-1.fc26.x86_64

I would bet it is caused by enabled inplicit files provider.
Because you have the same user in /etc/passwd and in LDAP.

You can try workaround ro disable files provides which is enabled by fdefault in f26+.

Put "enable_files_domain = false" into "sssd" section in /etc/sssd/sssd.conf
I let other fellow developers to check log files.

(In reply to Lukas Slebodnik from comment #7)
> Put "enable_files_domain = false" into "sssd" section in /etc/sssd/sssd.conf

This helped, although I have no idea what it actually means. The man page description is not really helpful ...

SSSD is going to start handling also local users in F26+, this means that it finds a conflict between the local user and the ldap user because they have the same name. SSSD always give precedence to the user of the first domain (which is the local domain) and does not "fall back" on duplicates like the PAM stack does (this is to avoid leaking passwords to all backends and potentially causing user lockups).

So if you want to keep local users that have the same name as remote user (a bad idea in the common case) you'll have to disable SSSD's handling of local users, or change the order in which domains are searched (remote first).

HTH.

OK, so I think there are two issues here:
1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in f-26 to have the order of groups and passwd modules to be set to 'sss files'. I don't expect running authconfig --updateall to break this.

2) Your PAM configuration is strange, pam_unix is called always and not only for local users which triggers the issue Simo talked about. Because starting with F-26 sssd also handles local users, but you also have a local user with the same name as the remote user, the request eventually goes to pam_sss, but because the files domain is always consulted first, the Kerberos password doesn't reach the remote server.

I wonder how you generated the PAM stack, was it also authconfig?

(In reply to Jakub Hrozek from comment #10)
> I wonder how you generated the PAM stack, was it also authconfig?

When I discovered that I can't login using my kerberos password anymore, I certainly tried:

~~~
# mv /etc/sysconfig/authconfig{,.bak}
~~~

and then enabling several options via `authconfig --enable` call, such as:

~~~
# autoconfig --enablesysnetauth
# authconfig --enablesssd
# authconfig --enablesssdauth
# authconfig --enablesssdauthprompting
~~~

Not sure if I enabled anything else, probably not.

I also tried revert from authconfig-7.0.0-1.fc26 to authconfig-6.2.10-16.fc26 at some point, but it did not appeared to help, so I am back to the latest.

I am not aware of any other modification I would do by some other means.

(In reply to Jakub Hrozek from comment #10)
> OK, so I think there are two issues here:
> 1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in
> f-26 to have the order of groups and passwd modules to be set to 'sss
> files'. I don't expect running authconfig --updateall to break this.
> 
Yes, but IIUC it did not work with default nsswitch from glibc either.

> 2) Your PAM configuration is strange, pam_unix is called always and not only
> for local users which triggers the issue Simo talked about. Because starting
> with F-26 sssd also handles local users, but you also have a local user with
> the same name as the remote user, the request eventually goes to pam_sss,
> but because the files domain is always consulted first, the Kerberos
> password doesn't reach the remote server.
> 
sssd handle local users; but IIRC pam_sss.so cannot handle passwords from /etc/shadow. Therefore it does not make a sense to contact domain implicit_files
from pam responder.

[sssd[pam]] [get_client_cred] (0x4000): Client creds: euid[0] egid[16025] pid[24568].
[sssd[pam]] [setup_client_idle_timer] (0x4000): Idle timer re-set for client [0x55ae39048630][24]
[sssd[pam]] [accept_fd_handler] (0x0400): Client connected!
[sssd[pam]] [sss_cmd_get_version] (0x0200): Received client version [3].
[sssd[pam]] [sss_cmd_get_version] (0x0200): Offered version [3].
[sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate
[sssd[pam]] [sss_domain_get_state] (0x1000): Domain redhat.com is Active
[sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'vondruch' matched without domain, user is vondruch
[sssd[pam]] [pam_print_data] (0x0100): command: SSS_PAM_AUTHENTICATE
[sssd[pam]] [pam_print_data] (0x0100): domain: not set
[sssd[pam]] [pam_print_data] (0x0100): user: vondruch
[sssd[pam]] [pam_print_data] (0x0100): service: sudo
[sssd[pam]] [pam_print_data] (0x0100): tty: /dev/pts/10
[sssd[pam]] [pam_print_data] (0x0100): ruser: vondruch
[sssd[pam]] [pam_print_data] (0x0100): rhost: not set
[sssd[pam]] [pam_print_data] (0x0100): authtok type: 1
[sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0
[sssd[pam]] [pam_print_data] (0x0100): priv: 0
[sssd[pam]] [pam_print_data] (0x0100): cli_pid: 24568
[sssd[pam]] [pam_print_data] (0x0100): logon name: vondruch
[sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/implicit_files/vondruch@implicit_files]
[sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [vondruch@implicit_files]
[sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [vondruch@implicit_files@implicit_files]
[sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is vondruch@implicit_files
[sssd[pam]] [LOCAL_pam_handler] (0x0100): LOCAL pam handler.
[sssd[pam]] [LOCAL_pam_handler] (0x0020): No password stored.
[sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [4]: Systémová chyba.
[sssd[pam]] [filter_responses] (0x0100): [pam_response_filter] not available, not fatal.
[sssd[pam]] [pam_reply] (0x0200): blen: 31

(In reply to Lukas Slebodnik from comment #12)
> (In reply to Jakub Hrozek from comment #10)
> > OK, so I think there are two issues here:
> > 1) authconfig has fubared the nsswitch. I expect the 'vanilla' nsswitch in
> > f-26 to have the order of groups and passwd modules to be set to 'sss
> > files'. I don't expect running authconfig --updateall to break this.
> > 
> Yes, but IIUC it did not work with default nsswitch from glibc either.
> 
> > 2) Your PAM configuration is strange, pam_unix is called always and not only
> > for local users which triggers the issue Simo talked about. Because starting
> > with F-26 sssd also handles local users, but you also have a local user with
> > the same name as the remote user, the request eventually goes to pam_sss,
> > but because the files domain is always consulted first, the Kerberos
> > password doesn't reach the remote server.
> > 
> sssd handle local users; 
> but IIRC pam_sss.so cannot handle passwords from
> /etc/shadow. Therefore it does not make a sense to contact domain
> implicit_files
> from pam responder.

OK, for now we could return an error that would iterate to the other domain. But when our files provider supports auth as well, we need our users to migrate..

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3341

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

I think I'm hitting this bug. I am not able to login to my kerberos realm. I kept the logs. kinit after login works. Yes, I have the same user/passwd for local account and kerberos. But f26 always uses the local account. How can I change the order in which domains are searched so the my rdc is first? After reading this bug that might solve my issue.

/etc/sssd/sssd.conf
[sssd]
domains = files
services = nss, pam

[pam]
debug_level = 9

[domain/files]
id_provider = files
auth_provider = krb5
debug_level = 9

krb5_server = panther.montclaire.local
krb5_realm = MONTCLAIRE.LOCAL


/etc/nsswitch.conf
#
# /etc/nsswitch.conf
#
# An example Name Service Switch config file. This file should be
# sorted with the most-used services at the beginning.
#
# The entry '[NOTFOUND=return]' means that the search for an
# entry should stop if the search in the previous entry turned
# up nothing. Note that if the search failed due to some other reason
# (like no NIS server responding) then the search continues with the
# next entry.
#
# Valid entries include:
#
#	nisplus			Use NIS+ (NIS version 3)
#	nis			Use NIS (NIS version 2), also called YP
#	dns			Use DNS (Domain Name Service)
#	files			Use the local files
#	db			Use the local database (.db) files
#	compat			Use NIS on compat mode
#	hesiod			Use Hesiod for user lookups
#	[NOTFOUND=return]	Stop searching if not found so far
#

# To use db, put the "db" in front of "files" for entries you want to be
# looked up first in the databases
#
# Example:
#passwd:    db files nisplus nis
#shadow:    db files nisplus nis
#group:     db files nisplus nis

passwd:    files sss
shadow:    files sss
group:     files sss

#hosts:     db files nisplus nis dns
hosts:     files mdns4_minimal [NOTFOUND=return] dns myhostname

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:  files sss

netgroup:  files sss

publickey:  nisplus

automount: files
aliases:    files nisplus

(In reply to louisgtwo from comment #16)
> I think I'm hitting this bug. I am not able to login to my kerberos realm. I
> kept the logs. kinit after login works. Yes, I have the same user/passwd for
> local account and kerberos. But f26 always uses the local account. How can I
> change the order in which domains are searched so the my rdc is first? After
> reading this bug that might solve my issue.
> 
> /etc/sssd/sssd.conf
> [sssd]
> domains = files
> services = nss, pam
> 
> [pam]
> debug_level = 9
> 
> [domain/files]
> id_provider = files
> auth_provider = krb5
> debug_level = 9
> 
> krb5_server = panther.montclaire.local
> krb5_realm = MONTCLAIRE.LOCAL
> 
> 
> /etc/nsswitch.conf
> #
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be
> # sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an
> # entry should stop if the search in the previous entry turned
> # up nothing. Note that if the search failed due to some other reason
> # (like no NIS server responding) then the search continues with the
> # next entry.
> #
> # Valid entries include:
> #
> #	nisplus			Use NIS+ (NIS version 3)
> #	nis			Use NIS (NIS version 2), also called YP
> #	dns			Use DNS (Domain Name Service)
> #	files			Use the local files
> #	db			Use the local database (.db) files
> #	compat			Use NIS on compat mode
> #	hesiod			Use Hesiod for user lookups
> #	[NOTFOUND=return]	Stop searching if not found so far
> #
> 
> # To use db, put the "db" in front of "files" for entries you want to be
> # looked up first in the databases
> #
> # Example:
> #passwd:    db files nisplus nis
> #shadow:    db files nisplus nis
> #group:     db files nisplus nis
> 
> passwd:    files sss
> shadow:    files sss
> group:     files sss
> 
> #hosts:     db files nisplus nis dns
> hosts:     files mdns4_minimal [NOTFOUND=return] dns myhostname
> 
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:        nisplus [NOTFOUND=return] files
> #ethers:     nisplus [NOTFOUND=return] files
> #netmasks:   nisplus [NOTFOUND=return] files
> 
> bootparams: nisplus [NOTFOUND=return] files
> 
> ethers:     files
> netmasks:   files
> networks:   files
> protocols:  files
> rpc:        files
> services:  files sss
> 
> netgroup:  files sss
> 
> publickey:  nisplus
> 
> automount: files
> aliases:    files nisplus

Your case is different because you use id_provider files.
And I already replied to your mail on sssd-users.

I have a lab of computers running Fedora 26 (fully updated as of today).  I just did a simple realm join and ding, AD login works for our students.

With Fedora 27 (fully updated as of today) it joins ok, but authentication fails.

My / partition got full (I do not have /var as a separate partition) because /var/log/sssd/sssd_kcm.log was 50G+.  I see a ton of these.

(Thu Dec 21 15:37:44 2017) [sssd[kcm]] [kcm_recv] (0x0010): Failed to parse data (74, Bad message), aborting client 

They are trigger upon an attempted login with an AD account

Here's what I see in the journal (I replaced the real username with USERNAME):

 ---- SSH login
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu sshd[1846]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=127.0.0.1 user=USERNAME
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_AUTH pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="USERNAME" exe="/usr/sbin/sshd" hostname=127.0.0.1 addr=127.0.0.1 terminal=ssh res=failed'
Dec 21 15:43:00 bz-cs-cslab1l.msu.montana.edu sshd[1846]: pam_sss(sshd:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:43:01 bz-cs-cslab1l.msu.montana.edu sshd[1846]: Failed password for USERNAME from 127.0.0.1 port 60790 ssh2
Dec 21 15:43:01 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_AUTH pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=password acct="USERNAME" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed'
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu audit[1846]: CRYPTO_KEY_USER pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=destroy kind=session fp=? direction=both spid=1847 suid=74 rport=60790 laddr=127.0.0.1 lport=22  exe="/usr/sbin/sshd" hostname=? addr=127.
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu sshd[1846]: Connection closed by authenticating user USERNAME 127.0.0.1 port 60790 [preauth]
Dec 21 15:43:36 bz-cs-cslab1l.msu.montana.edu audit[1846]: USER_LOGIN pid=1846 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="USERNAME" exe="/usr/sbin/sshd" hostname=? addr=127.0.0.1 terminal=ssh res=failed'

 ---- CONSOLE login
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu login[3614]: pam_sss(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=tty2 ruser= rhost= user=USERNAME
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu audit[3614]: USER_AUTH pid=3614 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="USERNAME" exe="/usr/bin/login" hostname=bz-cs-cslab1l.msu.montana.edu addr=? terminal=tty2 res=failed'
Dec 21 15:48:56 bz-cs-cslab1l.msu.montana.edu login[3614]: pam_sss(login:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:48:59 bz-cs-cslab1l.msu.montana.edu login[3614]: FAILED LOGIN 1 FROM tty2 FOR USERNAME, Authentication failure
Dec 21 15:48:59 bz-cs-cslab1l.msu.montana.edu audit[3614]: USER_LOGIN pid=3614 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:local_login_t:s0-s0:c0.c1023 msg='op=login id=608472194 exe="/usr/bin/login" hostname=bz-cs-cslab1l.msu.montana.edu addr=? terminal=tty2 res=failed'

 ---- LightDM login
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=USERNAME
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_sss(lightdm:auth): received for user USERNAME: 6 (Permission denied)
Dec 21 15:48:42 bz-cs-cslab1l.msu.montana.edu lightdm[3507]: pam_kwallet5(lightdm:auth): (null): pam_sm_authenticate

After trying those 3 login attempts the /var/log/sssd/sssd_kcm.log file went from 0 bytes (I had cat /dev/null > /var/log/sssd/ssd_kcm.log a minute prior) to 15GB.  Not quote a DoS attack, but close.  A few more logins and my hard drive will be full again.

HELP!

I only have a short winter break before the Spring semester starts and if I can't get this solved, I'll have to stick with Fedora 26.

Hmm, it seems the logging issue was caused by the only config edit I made to try to remedy the issue (I edited /etc/sysconfig/authconfig and changed FORCELEGACY=no to FORCELEGACY=yes).  I have reverted that change and rebooted and the disk filling logging has ceased.

The login failures for AD accounts continue though.

(In reply to Scott Dowdle from comment #19)
> Hmm, it seems the logging issue was caused by the only config edit I made to
> try to remedy the issue (I edited /etc/sysconfig/authconfig and changed
> FORCELEGACY=no to FORCELEGACY=yes).  I have reverted that change and
> rebooted and the disk filling logging has ceased.
> 

FORCELEGACY=YES IIRC configures pam_krb5 (you could confirm or deny this with e.g. cat /etc/pam.d/system-auth) so but I'm stumped as how this would help since the ticket itself would still be stored in sssd-kcm UNLESS pam_krb5 overrides the KRB5CCNAME. When you login with this workaround and run 'klist', does the ccache start with FILE or KCM?

> The login failures for AD accounts continue though.

Could you post the sssd logs please?

btw I'm sorry if the comments are delayed, but most of the SSSD developers already started their Christmas break..

Understood about the holidays.  I'm taking 5 days off myself... but I'll get those logs posted when I get back to work.

Regarding the change to the /etc/sysconfig/authconfig file... I must admit I don't know how the various authentication methods work nor their mechanics.  I tried that changed just because I found that as a possible solution in a web search.  It didn't work, so I reverted it.  In this case the change had the obvious negative side-effect of making the logs blow up.  If it had worked, I would have mentioned it and asked why.  I definitely don't like to do monkey-see-monkey-do fixes without understanding why especially when many config changes come with security implications.  Not every solution is an acceptable fix.

Looking at the various contents of /var/log/sssd/* nothing is jumping out at me. Mostly just a lot of SIGTERM killing children from the shutting down of the service at reboot.

I was doing a journald -f when logging in from the console, ssh, and from lightdm-gtk and provided the entries in comment # 18.

getent passwd {adusername} is returning good info.

I would really like to help you help me but I'm not sure what else to provide.

I would like to help you, but without more logs, it will be difficult.

I think you are more likely to be hitting https://bugzilla.redhat.com/show_bug.cgi?id=1494843 than the original issue in this BZ, because this BZ is about local accounts using Kerberos authentication.

In https://bugzilla.redhat.com/show_bug.cgi?id=1494843 there are some instructions how to get log files as well as a possible workaround that might allow you to get along with F-27 without KCM credential cache - the workaround is in the opening comment.

Thanks for the info Jakub.  I ended up nuking the F27 system I was working with to make an image and just keeping F26 on the systems... which continues to work fine.

I'm not really doing anything out of the ordinary so I'm guessing the bug I'm having (which as you mention doesn't map to this particular bug report very well) should be easily reproducible... unless of course there is something out-of-the-ordinary with the AD we have on campus... that I do not manage.

All I can say is that it works great in F26 but not F27.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.