[Freeipa-users] Fwd: Windows authentication against FreeIPA documentation question.
That is the perfect explanation. For redundancy sake I would recommend to add change this part: 7. *** REBOOT *** 8. Log in as [user]@[REALM] with the initial password, you will be prompted to change the password then logged in. to 7. *** REBOOT *** 8. If you don't use an AD-trust add user accounts for all users that need to be able to log in. Do not set up a password for those users. 9. Log in as [user]@[REALM] with the initial password, you will be prompted to change the password then logged in. # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Windows authentication against FreeIPA documentation question.
Regarding: http://freeipa.org/page/Windows_authentication_against_FreeIPA I noticed that I have to create a matching user on the windows machine before the user can log in. I don't have to set the password, but I do have to add a user as the local admin on that windows machine. windows 7 32 bit in this case. Am I missing something or is the documentation missing something? # Han -- ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
I've got it running. Of course you shouldn't expect passwordless logins to
work but it's much better than having everyone knowing the passwords.
The document that helped me setting up the cisco part was this one:
http://wiki.freeradius.org/vendor/Cisco
And the magic to add to the configfiles:
In client.conf; somerandompass is also used in the cisco config.
client 192.168.2.0/16 {
secret= somerandompass
shortname = someshortname
nastype = cisco
}
And in the file users; the last line throws users directly to the "root"
shell:
DEFAULT Auth-Type = Kerberos
Service-Type = NAS-Prompt-User, cisco-avpair = "shell:priv-lvl=15"
Now all I have to figure out is how to set up using eap-tls. The relevant
log-message is:
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeipa radius cisco
This might be somewhat off-topic but I'll ask anyway.
First my questions:
How do I get the cisco device -- a 3750 with the latest software image --
to use EAP-TTLS and what am I missing for the rest.
I've set up radius to use kerberos: kerberos seems to like it when I log on
with ssh on the cisco:
Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.2.74: NEEDED_PREAUTH: h...@domain.at for
krbtgt/domain...@domain.at, Additional pre-authentication required
Jan 16 17:33:34 auth-ipa.domain.at krb5kdc[9251](info): AS_REQ (4 etypes
{18 17 16 23}) 192.168.2.74: ISSUE: authtime 1358354014, etypes {rep=18
tkt=18 ses=18}, h...@domain.at for krbtgt/domain...@domain.at
Allas radius does not.
rad_recv: Access-Request packet from host 192.168.2.99 port 1645, id=14,
length=91
User-Name = "h...@realm.at"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
# Executing section authorize from file /etc/raddb//sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] Looking up realm "REALM.AT" for User-Name = "h...@realm.at"
[suffix] Found realm "REALM.AT"
[suffix] Adding Stripped-User-Name = "hb"
[suffix] Adding Realm = "REALM.AT"
[suffix] Proxying request from user hb to realm REALM.AT
[suffix] Preparing to proxy authentication request to realm "REALM.AT"
++[suffix] returns updated
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
++[pap] returns noop
WARNING: Empty pre-proxy section. Using default return values.
Sending Access-Request of id 149 to 127.0.0.1 port 1812
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator := 0x
Proxy-State = 0x3134
Proxying request 9 to home server 127.0.0.1 port 1812
Sending Access-Request of id 149 to 127.0.0.1 port 1812
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator := 0x
Proxy-State = 0x3134
Going to the next request
Waking up in 0.9 seconds.
rad_recv: Access-Request packet from host 127.0.0.1 port 1814, id=149,
length=102
User-Name = "hb"
User-Password = "hidden"
NAS-Port = 1
NAS-Port-Id = "tty1"
NAS-Port-Type = Virtual
Calling-Station-Id = "192.168.2.73"
NAS-IP-Address = 192.168.2.99
Message-Authenticator = 0xf42c5bcf8d1c09945833967ce22f9690
Proxy-State = 0x3134
# Executing section authorize from file /etc/raddb//sites-enabled/default
+- entering group authorize {...}
++[preprocess] returns ok
++[chap] returns noop
++[mschap] returns noop
++[digest] returns noop
[suffix] No '@' in User-Name = "hb", looking up realm NULL
[suffix] No such realm "NULL"
++[suffix] returns noop
[eap] No EAP-Message, not doing EAP
++[eap] returns noop
[files] users: Matched entry DEFAULT at line 206
++[files] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] WARNING! No "known good" password found for the user. Authentication
may fail because of this.
++[pap] returns noop
Found Auth-Type = Kerberos
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group Kerberos {...}
rlm_krb5: [hb] krb5_sname_to_principal failed: Hostname cannot be
canonicalized
++[krb5] returns reject
Failed to authenticate the user.
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> hb
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Delaying reject of request 10 for 1 seconds
Going to the next request
Waking up in 0.9 seconds.
Sending delayed reject for request 10
Sending Access-Reject of id 149 to 127.0.0.1 port 1814
Proxy-State = 0x3134
Waking up in 4.9 seconds.
rad_recv: Access-Reject packet from host 127.0.0.1 port 1812, id=149,
length=24
Proxy-State = 0x3134
# Executing section post-proxy from file /etc/raddb//sites-enabled/default
+- entering group post-proxy {...}
[eap] No pre-existing handler found
++[eap] returns noop
Using Post-Auth-Type Reject
# Executing group from file /etc/raddb//sites-enabled/default
+- entering group REJECT {...}
[attr_filter.access_reject] expand: %{User-Name} -> h...@realm.at
attr_filter: Matched entry DEFAULT at line 11
++[attr_filter.access_reject] returns updated
Sending Access-Reject of id 14 to 192.168.2.99 port 1645
Finished request 9.
Going to the next request
Waking up in 4.9 seconds.
Cleaning up request 10 ID 149 with timestamp +2998
Cleaning up request 9 ID 14 with timestamp
[Freeipa-users] freeipa radius cisco
Hi, Since most of our cisco images do not support encryption the apparent way to go is using radius which is supported by most cisco devices. What is the current status for making this wonderful idea work in the real world. Thanks in advance. # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication with latest putty fails
I just had a long and fruitfull debugging session with Sumit and this is what we discovered. The default settings do run fine for linux machines but for windows hosts they do not suffice. Sumit is submitting bug reports and hopefully they will be applied to the next 2.2.x release. This problem does not exist with version 3.x The workaround for 2.2.x releases is: For any target machine you want to enable forwarding tickets which have to be accessible with putty you will have to add the ok_as_delegate flag. To do that run the following commands on the ipa-server: # ipa host-mod --addattr='objectclass=krbTicketPolicyAux' destinationhost.domain # kadmin.local -q 'modprinc +ok_as_delegate host/destinationhost.domain@REALM' So far I working tickets on the destination machine if I used centrify putty to log in. This didn't work with the stock version of putty allas. # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication with latest putty fails
There was something going on with a firewall blocking something and that windows host didn't have a cert yet. But still: Using Kerberos authentication Using principal fh@REALM Got host ticket host/test-server-ipa.domain@REALM Using username "fh". Successful Kerberos connection Last login: Mon Jan 7 07:38:19 2013 from ipa-w7.domain [fh@test-server-ipa ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) klist on the host shows all tickets are forwordable and the forwarding option in both putty versions is on. Which version of FreeIPA are you using? There are issues in older > version which prevents kadmin.local from working. > The default stable: [root@auth-ipa ssl_for_ipa-w7]# rpm -qa |grep ipa- ipa-client-2.2.0-16.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-admintools-2.2.0-16.el6.x86_64 ipa-server-selinux-2.2.0-16.el6.x86_64 ipa-server-2.2.0-16.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-python-2.2.0-16.el6.x86_64 On Mon, Jan 7, 2013 at 9:38 AM, Sumit Bose wrote: > On Mon, Jan 07, 2013 at 09:15:41AM +0100, Han Boetes wrote: > > On Fri, Jan 4, 2013 at 6:52 PM, Sumit Bose wrote: > > > > > About delegating credentials, you might need to set the ok_as_delegate > > > flag on the host/* service ticket. To do this you can call kadmin.local > > > on the IPA server and then use > > > > > > modprinc +ok_as_delegate host/test-server-ipa.realm@REALM > > > > > > to set the flag. > > > > > > > I don't know why this host would have this flag set differently from > other > > Does it mean there are other windows hosts where delegation already > works as expected? AFAIK the Linux OpenSSH client does not check > this flag and forwards the credentials depending on the command line > options, but it looks like putty on Windows checks this flag. > > > hosts. And I get this error while trying to set or unset this flag. > > > > kadmin.local: modprinc +ok_as_delegate host/ipa-w7.domain@REALM > > modify_principal: Kerberos database internal error while modifying > > "host/ipa-w7.domain@REALM > > > > For any other host as well BTW. I can't find anything relevant in the log > > files. > > Which version of FreeIPA are you using? There are issues in older > version which prevents kadmin.local from working. > > bye, > Sumit > > > > > -- > > > > > > > > # Han > -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication with latest putty fails
On Fri, Jan 4, 2013 at 6:52 PM, Sumit Bose wrote: > About delegating credentials, you might need to set the ok_as_delegate > flag on the host/* service ticket. To do this you can call kadmin.local > on the IPA server and then use > > modprinc +ok_as_delegate host/test-server-ipa.realm@REALM > > to set the flag. > I don't know why this host would have this flag set differently from other hosts. And I get this error while trying to set or unset this flag. kadmin.local: modprinc +ok_as_delegate host/ipa-w7.domain@REALM modify_principal: Kerberos database internal error while modifying "host/ipa-w7.domain@REALM For any other host as well BTW. I can't find anything relevant in the log files. -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication with latest putty fails
Your information about the quest putty version seems to be outdated. ;-) Quest Softare no longer maintains recent releases of PuTTY. To obtain the latest stable release of PuTTY please goto PuTTY Download Page * The functionality that was provided by Quest Software's PuTTY packages have now been included in the latest releases of PuTTY, making Quest PuTTY obsolete. I'm testdriving the centrify version at the moment and... ~/debug% cat ~/out Using Kerberos authentication Using principal fh@REALM Got host ticket host/test-server-ipa.domain@REALM login as fh@REALM Kerberos authentication failed. Please check 1) Unix login name is correct 2) Target service principal name is correct 3) Kerberos authentication is enabled in SSH server 4) Clock in the host is syncrhonized with the clock in AD fh@REALM@test-server-ipa's password: Last login: Fri Jan 4 14:51:25 2013 from ipa-w7.domain [fh@test-server-ipa ~]$ klist Ticket cache: FILE:/tmp/krb5cc_1554800011_JDgpIu5465 Default principal: fh@REALM Valid starting ExpiresService principal 01/04/13 14:52:49 01/05/13 14:52:49 krbtgt/REALM@REALM [fh@test-server-ipa ~]$ That's does provide a valid ticket but not a passwordless login. Actually I have to enter a pass twice here! On Fri, Jan 4, 2013 at 4:25 PM, Sumit Bose wrote: > On Fri, Jan 04, 2013 at 04:14:36PM +0100, Han Boetes wrote: > > You are absolutely right; the credentials aren't forwarded. > > > > I have enabled the option "allow gssapi credential delegation". So one > > would expect that it should work. > > > > I just installed the mit kerberos tools and I can see all the options and > > forwarding tickets is allowed according to the interface. Also putty is > now > > using the mit kerberos dll; gssapi32.dll and still I get the same > results. > > > > So the proper question is: how do I get putty to really forward the > > credentials? > > This might be an issue with your putty version. Can you try Quest's > version of putty http://rc.quest.com/topics/putty/ , if you are not > already using it? > > HTH > > bye, > Sumit > > > > > > > On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden > wrote: > > > > > Han Boetes wrote: > > > > > >> I've set up windows with the instructions given over here: > > >> > > >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA< > http://freeipa.com/page/Windows_authentication_against_FreeIPA> > > >> > > >> And all seems to be working fine. After I run klist I see valid > tickets: > > >> > > >> Microsoft Windows [Version 6.1.7601] > > >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. > > >> > > >> C:\Users\fh>klist > > >> > > >> Aktuelle Anmelde-ID ist 0:0x153b25 > > >> > > >> Zwischengespeicherte Tickets: (1) > > >> > > >> #0> Client: fh @ REALM > > >> Server: krbtgt/REALM @ REALM > > >> KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 > > >> Ticketkennzeichen 0x40e1 -> forwardable renewable initial > > >> pre_authen > > >> t name_canonicalize > > >> Startzeit: 1/4/2013 14:03:11 (lokal) > > >> Endzeit: 1/5/2013 14:03:11 (lokal) > > >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) > > >> Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 > > >> > > >> > > >> I can do a passwordless login with the latest putty with kerberos > > >> authentication, I disabled password and key logins. And then on the > > >> host I checked klist and got this: > > >> > > >> [fh@test-server-ipa ~]$ klist > > >> klist: No credentials cache found (ticket cache > > >> FILE:/tmp/krb5cc_1554800011) > > >> > > >> sudo also doesn't work. To test the setup I did the same from linux > host > > >> and login in, sudo, klist etc etc all work fine. So I checked the sshd > > >> -d output difference and the only difference I see is: > > >> > > >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 > > >> -debug1: Received some client credentials > > >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 > > >> +debug1: Got no client credentials > > >> > > >> Where .73 is the linux host and .56 is the windows host. > > >> > > >> What am I missing here? > > >> > > > > > > The problem isn't that authentication fails, it is that the credentials > > > aren't forwarded, right? > > > > > > Does putty support this? > > > > > > rob > > > > > > > > > > > > -- > > > > > > > > # Han > > > ___ > > Freeipa-users mailing list > > Freeipa-users@redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > ___ > Freeipa-users mailing list > Freeipa-users@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] authentication with latest putty fails
You are absolutely right; the credentials aren't forwarded. I have enabled the option "allow gssapi credential delegation". So one would expect that it should work. I just installed the mit kerberos tools and I can see all the options and forwarding tickets is allowed according to the interface. Also putty is now using the mit kerberos dll; gssapi32.dll and still I get the same results. So the proper question is: how do I get putty to really forward the credentials? On Fri, Jan 4, 2013 at 3:58 PM, Rob Crittenden wrote: > Han Boetes wrote: > >> I've set up windows with the instructions given over here: >> >> http://freeipa.com/page/**Windows_authentication_**against_FreeIPA<http://freeipa.com/page/Windows_authentication_against_FreeIPA> >> >> And all seems to be working fine. After I run klist I see valid tickets: >> >> Microsoft Windows [Version 6.1.7601] >> Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. >> >> C:\Users\fh>klist >> >> Aktuelle Anmelde-ID ist 0:0x153b25 >> >> Zwischengespeicherte Tickets: (1) >> >> #0> Client: fh @ REALM >> Server: krbtgt/REALM @ REALM >> KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 >> Ticketkennzeichen 0x40e1 -> forwardable renewable initial >> pre_authen >> t name_canonicalize >> Startzeit: 1/4/2013 14:03:11 (lokal) >> Endzeit: 1/5/2013 14:03:11 (lokal) >> Erneuerungszeit: 1/11/2013 14:03:11 (lokal) >> Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 >> >> >> I can do a passwordless login with the latest putty with kerberos >> authentication, I disabled password and key logins. And then on the >> host I checked klist and got this: >> >> [fh@test-server-ipa ~]$ klist >> klist: No credentials cache found (ticket cache >> FILE:/tmp/krb5cc_1554800011) >> >> sudo also doesn't work. To test the setup I did the same from linux host >> and login in, sudo, klist etc etc all work fine. So I checked the sshd >> -d output difference and the only difference I see is: >> >> -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 >> -debug1: Received some client credentials >> +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 >> +debug1: Got no client credentials >> >> Where .73 is the linux host and .56 is the windows host. >> >> What am I missing here? >> > > The problem isn't that authentication fails, it is that the credentials > aren't forwarded, right? > > Does putty support this? > > rob > > -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] authentication with latest putty fails
I've set up windows with the instructions given over here: http://freeipa.com/page/Windows_authentication_against_FreeIPA And all seems to be working fine. After I run klist I see valid tickets: Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten. C:\Users\fh>klist Aktuelle Anmelde-ID ist 0:0x153b25 Zwischengespeicherte Tickets: (1) #0> Client: fh @ REALM Server: krbtgt/REALM @ REALM KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40e1 -> forwardable renewable initial pre_authen t name_canonicalize Startzeit: 1/4/2013 14:03:11 (lokal) Endzeit: 1/5/2013 14:03:11 (lokal) Erneuerungszeit: 1/11/2013 14:03:11 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 I can do a passwordless login with the latest putty with kerberos authentication, I disabled password and key logins. And then on the host I checked klist and got this: [fh@test-server-ipa ~]$ klist klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_1554800011) sudo also doesn't work. To test the setup I did the same from linux host and login in, sudo, klist etc etc all work fine. So I checked the sshd -d output difference and the only difference I see is: -Postponed gssapi-with-mic for fh from 192.168.2.73 port 50334 ssh2 -debug1: Received some client credentials +Postponed gssapi-with-mic for fh from 192.168.2.56 port 49168 ssh2 +debug1: Got no client credentials Where .73 is the linux host and .56 is the windows host. What am I missing here? -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] gotcha for windows hosts: hostnames should not exceed 15 chars
Perhaps it's worth mentioning that hostnames for windows client can not exceed 15 chars on this page. http://freeipa.org/page/Windows_authentication_against_FreeIPA I ran into it and it costed me a day trying to fix it. I had to reinstall my test machine to make it work properly. # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] login with kerberos on a webserver, just like with the ipa interface.
Sorry I couldn't reply earlier, somehow I don't receive my own messages. I had set chrome to --auth-server-whitelist=ipa-server.domain.com, and not --auth-server-whitelist=*domain.com On Thu, Dec 20, 2012 at 5:33 PM, Simo Sorce wrote: > On Thu, 2012-12-20 at 16:38 +0100, Han Boetes wrote: > > Hi, > > > > > > I followed http://freeipa.org/page/Apache_SNI_With_Kerberos to enable > > login in to a webserver with kerberos tickets. I followed everything > > to the letter and all looks well. > > > > > > I can log in with a username and password, but when I set the > > httpd.conf entry to > > > > > > KrbMethodK5Passwd off > > > > > > > > I can't log in. What works great with the ipa admin interface does not > > work with this recipe. > > > > I even compared it to /etc/httpd/conf.d/ipa.conf and added the > > KrbAuthRealms setting but to no avail. > > > > > > > > Adding KrbConstrainedDelegation on does not work alas. Although I am > > using centos 6.3 > > > > > > I checked the http logfiles and the /var/log/krb5kdc.log, everything > > else on that host works fine. I can log in without a password and sudo > > -s works like it should. > > > > > > Please help me debugging this issue. What am I missing? > > Are you using the same fully qualified name you have a keytab for ? > Do you see a ticket for the target server in the user ccache on the > client ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -- # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] login with kerberos on a webserver, just like with the ipa interface.
Hi, I followed http://freeipa.org/page/Apache_SNI_With_Kerberos to enable login in to a webserver with kerberos tickets. I followed everything to the letter and all looks well. I can log in with a username and password, but when I set the httpd.conf entry to KrbMethodK5Passwd off I can't log in. What works great with the ipa admin interface does not work with this recipe. I even compared it to /etc/httpd/conf.d/ipa.conf and added the KrbAuthRealms setting but to no avail. Adding KrbConstrainedDelegation on does not work alas. Although I am using centos 6.3 I checked the http logfiles and the /var/log/krb5kdc.log, everything else on that host works fine. I can log in without a password and sudo -s works like it should. Please help me debugging this issue. What am I missing? # Han ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
