On 02/23/2017 02:54 AM, babajuneed wrote:[color=blue]
Which version and Service Pack (SP) of SLES?
Ans:
SUSE Linux Enterprise Server 11 (x86_64)
VERSION = 11
PATCHLEVEL = 3[/color]
Have you tried SP4, or even better, SLES 12 SP2? I only ask because of
possible fixes, and in the case of SLES 12, much newer SSSD code.
[color=blue]
Do any other systems of yours, SLES or otherwise, work when doing this?
Ans;
We are facing this issue with SuSe servers only, we also have other
flavors of linux in our environment but for the AD authentication is
working fine.[/color]
Are they also using SSSD (vs. just LDAP) I presume, and, if so, which
version? Have you compared their configuration files with those from SLES?
[color=blue]
Anything interesting in the various logs, usually all under /var/log ?[/color]
What about those logs? I see your krb5.conf points to a few under
/var/log which may be interesting to tail as you try the login with a
password.
[color=blue]
Below is the krb5.conf file contents:
below entry in /etc/krb5.conf
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = fake.example.com.au
dns_lookup_realm = false
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = false
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
FAKE.EXAMPLE.COM.AU = {
kdc = server.fake.example.com.au
admin_server = FAKE.EXAMPLE.COM.AU
}
FAKE.EXAMPLE.COM.AU = {
}[/color]
Is there a reason you have this first, blank, entry? I am not an SSSD
expert, but having two, one blank, seems like a non-required, maybe
non-good, thing.
[color=blue]
FAKE.EXAMPLE.COM.AU = {
kdc = server1.fake.example.com.au
kdc = server2.fake.example.com.au
}
[domain_realm]
fake.example.com.au = FAKE.EXAMPLE.COM.AU
.fake.example.com.au = FAKE.EXAMPLE.COM.AU[/color]
What, if anything, do you see on the wire between the SLES box and the
windows domain controllers (DC) when you try the password-based
authentication? How does that compare with working systems?
#Summary printed to the screen.
sudo /usr/sbin/tcpdump -n -s 0 -i any not port 22
#All data written to a file (for proper analysis)
sudo /usr/sbin/tcpdump -n -s 0 -i any -v -w /tmp/lan.cap not port 22
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…