5:53 p.m.
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
6:06 p.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
6:16 p.m.
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
8:23 p.m.
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
11:12 p.m.
New subject: [SOLVED] cannot authenticate one user
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.
11:24 p.m.
New subject: [SOLVED] cannot authenticate one user
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
10:55 a.m.
New subject: [SOLVED] cannot authenticate one user
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.
3:04 p.m.
New subject: [SOLVED] cannot authenticate one user
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.
3:25 p.m.
New subject: [SOLVED] cannot authenticate one user
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
3:56 p.m.
New subject: [SOLVED] cannot authenticate one user
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
10:18 a.m.
New subject: [SOLVED] cannot authenticate one user
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
3:35 p.m.
New subject: [SOLVED] cannot authenticate one user
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.
3:47 p.m.
New subject: [SOLVED] cannot authenticate one user
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.
4:04 p.m.
New subject: [SOLVED] cannot authenticate one user
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
4:08 p.m.
New subject: [SOLVED] cannot authenticate one user
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(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
4234
days inactive
4236
days old
sssd-users@lists.fedorahosted.org
14 comments
4 participants
participants (4)
-
Dmitri Pal -
Jakub Hrozek -
Michael Cronenworth -
Ondrej Valousek