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
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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.
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
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
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
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.
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.
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
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 sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
sssd-users@lists.fedorahosted.org
-
Dmitri Pal -
Jakub Hrozek -
Michael Cronenworth -
Ondrej Valousek