cannot authenticate one user

[Michael Cronenworth]

Hello,

I have a Fedora 16 box that acts as a file server. Most people access it
via samba shares. People can also log in via SSH to get a shell. One
user (foobar) seems unable to log in via SSH though. The SSSD logs show
the following:

(Mon Sep 17 10:34:53 2012) [sssd[be[default]]] [be_get_account_info]
(0x0100): Got request for [3][1][name=foobar]
(Mon Sep 17 10:34:53 2012) [sssd[be[default]]] [acctinfo_callback]
(0x0100): Request processed. Returned 1,11,Offline

Some background:
- Fedora 16
- sssd-1.8.4-13.fc16.x86_64
- Users and password authentication is setup to use a Windows
  domain controller (not Samba)
- Kerberos is setup and I have valid cc files in /tmp
- Ran sss_cache -u foobar
- The user can log in successfully to my local Fedora 17 box that
  has an identical configuration for SSSD/KRB5.

I don't understand what "Offline" means or where else to look. I changed
my Windows password using a Windows computer and the Fedora 16 box
picked up my new password.

Thanks,
Michael

[Dmitri Pal]

On 09/17/2012 11:53 AM, Michael Cronenworth wrote:
> Hello,
>
> I have a Fedora 16 box that acts as a file server. Most people access it
> via samba shares. People can also log in via SSH to get a shell. One
> user (foobar) seems unable to log in via SSH though. The SSSD logs show
> the following:
>
> (Mon Sep 17 10:34:53 2012) [sssd[be[default]]] [be_get_account_info]
> (0x0100): Got request for [3][1][name=foobar]
> (Mon Sep 17 10:34:53 2012) [sssd[be[default]]] [acctinfo_callback]
> (0x0100): Request processed. Returned 1,11,Offline
>
> Some background:
> Fedora 16
> sssd-1.8.4-13.fc16.x86_64
> Users and password authentication is setup to use a Windows
> domain controller (not Samba)
> Kerberos is setup and I have valid cc files in /tmp
> Ran sss_cache -u foobar
> The user can log in successfully to my local Fedora 17 box that
> has an identical configuration for SSSD/KRB5.
>
> I don't understand what "Offline" means or where else to look. I changed
> my Windows password using a Windows computer and the Fedora 16 box
> picked up my new password.

The Offline status shows that the system is offline and that the
operation is performed against cache.
If you changed the user password on one system but the other system is
offline it would still expect the old password.

Please check if the user cal log using old password and also please
check what is wrong related to connectivity between this system and your
AD server. If system indicates that it is offline there is something
wrong with its connectivity.
> Thanks,
> Michael
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[Michael Cronenworth]

Dmitri Pal wrote:
> The Offline status shows that the system is offline and that the
> operation is performed against cache.
> If you changed the user password on one system but the other system is
> offline it would still expect the old password.

To reiterate: I changed my password on another machine and the F16 box
only authenticated me using the new password. The old password would not
work. A cache is not being used.
> Please check if the user cal log using old password and also please
> check what is wrong related to connectivity between this system and your
> AD server. If system indicates that it is offline there is something
> wrong with its connectivity.

My F16 and F17 boxes are on the same physical network as the AD. I can
ping the AD from the F16 box. I have even disabled the firewall and
SELinux. No success.

Are there any logs or debug levels to enable to see why SSSD thinks the
provider is "Offline" when it isn't?

Thanks,
Michael

[Dmitri Pal]

On 09/17/2012 12:16 PM, Michael Cronenworth wrote:
> Dmitri Pal wrote:
> > The Offline status shows that the system is offline and that the
> > operation is performed against cache.
> > If you changed the user password on one system but the other system is
> > offline it would still expect the old password.
>
> To reiterate: I changed my password on another machine and the F16 box
> only authenticated me using the new password. The old password would not
> work. A cache is not being used.
> > Please check if the user cal log using old password and also please
> > check what is wrong related to connectivity between this system and your
> > AD server. If system indicates that it is offline there is something
> > wrong with its connectivity.
>
> My F16 and F17 boxes are on the same physical network as the AD. I can
> ping the AD from the F16 box. I have even disabled the firewall and
> SELinux. No success.
>
> Are there any logs or debug levels to enable to see why SSSD thinks the
> provider is "Offline" when it isn't?

debug_level=9
/var/log/sssd/sssd_default.log

sssd.conf and krb5.conf would be helpful too.
> Thanks,
> Michael
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SOLVED] cannot authenticate one user

[Michael Cronenworth]

Dmitri Pal wrote:
> debug_level=9
> /var/log/sssd/sssd_default.log

Thanks.
> sssd.conf and krb5.conf would be helpful too.

The F16 (not working) and F17 (working) boxes have identical sssd.conf
and krb5.conf files. Verified by diff. The boxes are also using the same
DNS server (runs on the F16 box) with the exact same /etc/resolv.conf
file. I have attached the files for completeness.

The problem? The machine's FQDN was not set. Even though
/etc/sysconfig/network has it set, the "hostname -f" command did not
return the full domain name. The SRV requests SSSD was trying to perform
were against the machine name instead of the domain name. Setting the
FQDN got things working again. No conf file changes were required. I'm
not sure how the hostname got changed as this was working properly in
the past.

[SOLVED] cannot authenticate one user

[Dmitri Pal]

On 09/17/2012 05:12 PM, Michael Cronenworth wrote:
> Dmitri Pal wrote:
> > debug_level=9
> > /var/log/sssd/sssd_default.log
>
> Thanks.
> > sssd.conf and krb5.conf would be helpful too.
>
> The F16 (not working) and F17 (working) boxes have identical sssd.conf
> and krb5.conf files. Verified by diff. The boxes are also using the same
> DNS server (runs on the F16 box) with the exact same /etc/resolv.conf
> file. I have attached the files for completeness.
>
> The problem? The machine's FQDN was not set. Even though
> /etc/sysconfig/network has it set, the "hostname -f" command did not
> return the full domain name. The SRV requests SSSD was trying to perform
> were against the machine name instead of the domain name. Setting the
> FQDN got things working again. No conf file changes were required. I'm
> not sure how the hostname got changed as this was working properly in
> the past.

I am glad things worked out for you.
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SOLVED] cannot authenticate one user

[Jakub Hrozek]

On Mon, Sep 17, 2012 at 05:24:16PM -0400, Dmitri Pal wrote:
> On 09/17/2012 05:12 PM, Michael Cronenworth wrote:
> > Dmitri Pal wrote:
> > > debug_level=9
> > > /var/log/sssd/sssd_default.log
> >
> > Thanks.
> > > sssd.conf and krb5.conf would be helpful too.
> >
> > The F16 (not working) and F17 (working) boxes have identical sssd.conf
> > and krb5.conf files. Verified by diff. The boxes are also using the same
> > DNS server (runs on the F16 box) with the exact same /etc/resolv.conf
> > file. I have attached the files for completeness.
> >
> > The problem? The machine's FQDN was not set. Even though
> > /etc/sysconfig/network has it set, the "hostname -f" command did not
> > return the full domain name. The SRV requests SSSD was trying to perform
> > were against the machine name instead of the domain name. Setting the
> > FQDN got things working again. No conf file changes were required. I'm
> > not sure how the hostname got changed as this was working properly in
> > the past.
>
> I am glad things worked out for you.

You can also set the dns_discovery_domain to explicitly specify the
discovery domain the SSSD should be using.

In the absence of that parameter, the SSSD uses the domain part of the
host name.

[SOLVED] cannot authenticate one user

[Michael Cronenworth]

Jakub Hrozek wrote:
> You can also set the dns_discovery_domain to explicitly specify the
> discovery domain the SSSD should be using.
>
> In the absence of that parameter, the SSSD uses the domain part of the
> host name.

Thanks, that is good to know.

Instead of DNS discovery I went ahead and hard coded the local AD server
(ldap_uri/krb5_server). The server SSSD was using by default was the
primary AD located across a VPN and it was introducing a few second
delay in authentication due to the latency of the connection.

[SOLVED] cannot authenticate one user

[Ondrej Valousek]

> Thanks, that is good to know.
>
> Instead of DNS discovery I went ahead and hard coded the local AD server
> (ldap_uri/krb5_server). The server SSSD was using by default was the
> primary AD located across a VPN and it was introducing a few second
> delay in authentication due to the latency of the connection.

I had the same problem and instead of had-coding our local AD server (which is ugly) I used dns_discovery_domain in form of:
<your site name>._sites.<ad realm>
This way you ensure sssd is always using local AD controller to your site.

Ondrej

[SOLVED] cannot authenticate one user

[Michael Cronenworth]

Ondrej Valousek wrote:
> I had the same problem and instead of had-coding our local AD server
> (which is ugly) I used dns_discovery_domain in form of:
> <your site name>._sites.<ad realm>
> This way you ensure sssd is always using local AD controller to your site.

So if my AD was: test-ad-01.example.com

My conf file would look like:

dns_discovery_domain = test-ad-01._sites.example.com

?

Thanks,
Michael

[SOLVED] cannot authenticate one user

[Ondrej Valousek]

nope.
You need to use tool AD sites and services to create AD site first (you should have done that anyway if you have AD controllers behind a 
slow VPN link).
Ondrej

On 09/18/2012 03:56 PM, Michael Cronenworth wrote:
> Ondrej Valousek wrote:
> > I had the same problem and instead of had-coding our local AD server
> > (which is ugly) I used dns_discovery_domain in form of:
> > <your site name>._sites.<ad realm>
> > This way you ensure sssd is always using local AD controller to your site.
>
> So if my AD was: test-ad-01.example.com
>
> My conf file would look like:
>
> dns_discovery_domain = test-ad-01._sites.example.com
>
> ?
>
> Thanks,
> Michael
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

[SOLVED] cannot authenticate one user

[Michael Cronenworth]

Ondrej Valousek wrote:
> nope.
> You need to use tool AD sites and services to create AD site first (you
> should have done that anyway if you have AD controllers behind a slow
> VPN link).

OK, thanks. I am not an AD expert (nor the admin of the Windows network)
so I did not understand what you meant. I got the site name and tried:

dns_discovery_domain = Sitename._sites.example.com

The LDAP and KERBEROS services detected the correct server name, but the
KPASSWD service was "not found" so my system could not authenticate me.

[SOLVED] cannot authenticate one user

[Ondrej Valousek]

That's true. AD (for some reason) does not populate KDCs _kpasswd services for sites (only for the whole domain). You have to create the 
appropriate SRV _kpasswd records manually :-( .

On 09/19/2012 03:35 PM, Michael Cronenworth wrote:
> The LDAP and KERBEROS services detected the correct server name, but the KPASSWD service was "not found" so my system could not 
> authenticate me.

[SOLVED] cannot authenticate one user

[Jakub Hrozek]

On Wed, Sep 19, 2012 at 08:35:21AM -0500, Michael Cronenworth wrote:
> Ondrej Valousek wrote:
> > nope.
> > You need to use tool AD sites and services to create AD site first (you
> > should have done that anyway if you have AD controllers behind a slow
> > VPN link).
>
> OK, thanks. I am not an AD expert (nor the admin of the Windows network)
> so I did not understand what you meant. I got the site name and tried:
>
> dns_discovery_domain = Sitename._sites.example.com
>
> The LDAP and KERBEROS services detected the correct server name, but the
> KPASSWD service was "not found" so my system could not authenticate me.

For the record, the fact that the back end went offline if the kpasswd
server could not be resolved is a bug we fixed during the 1.9 development:
https://fedorahosted.org/sssd/ticket/1452

[SOLVED] cannot authenticate one user

[Ondrej Valousek]

Note (to be absolutely exact) that _both_ '_kpasswd' and '_kerberos' SRV records are usually missing in the _sites DNS zone (at least were 
missing in my AD).
Whereas the bug fix mentioned below would eliminate the need for _kpasswd, I believe _kerberos would still be needed.

Ondrej

On 09/19/2012 04:04 PM, Jakub Hrozek wrote:
> For the record, the fact that the back end went offline if the kpasswd
> server could not be resolved is a bug we fixed during the 1.9 development:
> https://fedorahosted.org/sssd/ticket/1452
> _______________________________________________
> sssd-users mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users