[Freeipa-users] Re: Unable to add AD group to new install

[Alexander Bokovoy via FreeIPA-users]

On ke, 20 syys 2017, Bobby Jones via FreeIPA-users wrote:

Hi:

I am trying to finish my integration of FreeIPA with Active Directory, but
when I try to add my group information it fails.

# ipa group-add-member ad_admins_external --external 'AD/Domain Admins'
  member group: AD\Domain Admins: trusted domain object not found

As far as I can tell, I have established a trust relationship between my
IPA realm (ipa.mydomain.com) and my AD domain (ad.mydomain.com). If I run
netdom query /d:AD.MYDOMAIN.COM TRUST I get:

<-   ipa.mydomain.com   Direct

I am assuming that the direction (<-) indicates that ipa trusts AD. From
the other side, everything looks ok to me:

# ipa trustdomain-find AD.MYDOMAIN.COM
 Domain name: AD.MYDOMAIN.COM
 Domain NetBIOS name: AD
 Domain Security Identifier: S-1-5-21-380002-327639-3459556696
 Domain enabled: True

Number of entries returned 1


In troubleshooting this, I ran:
# KRB5_TRACE=/dev/stderr kvno -S cifs ad.mydomain.com

is it really ad.mydomain.com as a host name? What is your real AD
domain? What is a real AD DC hostname?


The last two lines were:

[16487] 1505918874.707116: TGS request result: -1765328377/Server cifs/
ad.mydomain@ipa.mydomain.com not found in Kerberos database
kvno: Server cifs/ad.mydomain@ipa.mydomain.com not found in Kerberos
database while getting credentials for cifs/ad.mydomain@ipa.mydomain.com

This means IPA KDC doesn't know that ad.mydomain.com belongs to
realm AD.MYDOMAIN.COM. This should be suspicious.

Start from beginning. 


How exactly did you establish the trust? Show a command that was used to
establish trust.

If you can re-establish it, add 'log level = 10' to
/usr/share/ipa/smb.conf.empty and re-run 'ipa trust-add'. You'll get a
lot of details in /var/log/httpd/error_log that show what AD thinks
about the trust.




This led me to try the following (based on a tutorial I found), but with no
success:

# ipa service-add cifs/ad.mydomain@ipa.mydomain.com --force
ipa: ERROR: The host 'ad.mydomain.com' does not exist to add a service to.

I wonder what is this (a tutorial)? This is absolute nonsense.


I am running CentOS 7 with ipa 4.5; all AD servers are running server 2016.
If anyone has any pointers which could help with this, I'd appreciate it.
Debugging 4.5 is a new experience. Read my article about it: 
https://vda.li/en/docs/freeipa-debug-privsep/


However, for trust to AD nothing changed. If your KDC doesn't seem to
understand how to reach AD DCs for ad.mydomain.com, you have a
fundamental problem.

--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Unable to add AD group to new install

[Bobby Jones via FreeIPA-users]

Hi:

I am trying to finish my integration of FreeIPA with Active Directory, but
when I try to add my group information it fails.

# ipa group-add-member ad_admins_external --external 'AD/Domain Admins'
   member group: AD\Domain Admins: trusted domain object not found

As far as I can tell, I have established a trust relationship between my
IPA realm (ipa.mydomain.com) and my AD domain (ad.mydomain.com). If I run
netdom query /d:AD.MYDOMAIN.COM TRUST I get:

<-   ipa.mydomain.com   Direct

I am assuming that the direction (<-) indicates that ipa trusts AD. From
the other side, everything looks ok to me:

# ipa trustdomain-find AD.MYDOMAIN.COM
  Domain name: AD.MYDOMAIN.COM
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-380002-327639-3459556696
  Domain enabled: True

Number of entries returned 1


In troubleshooting this, I ran:
# KRB5_TRACE=/dev/stderr kvno -S cifs ad.mydomain.com
The last two lines were:

[16487] 1505918874.707116: TGS request result: -1765328377/Server cifs/
ad.mydomain@ipa.mydomain.com not found in Kerberos database
kvno: Server cifs/ad.mydomain@ipa.mydomain.com not found in Kerberos
database while getting credentials for cifs/ad.mydomain@ipa.mydomain.com

This led me to try the following (based on a tutorial I found), but with no
success:

# ipa service-add cifs/ad.mydomain@ipa.mydomain.com --force
ipa: ERROR: The host 'ad.mydomain.com' does not exist to add a service to.

I am running CentOS 7 with ipa 4.5; all AD servers are running server 2016.
If anyone has any pointers which could help with this, I'd appreciate it.

Thanks!

Bob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't log on using password when /tmp is full

[Lukas Slebodnik via FreeIPA-users]

On (19/09/17 18:46), Florence Blanc-Renaud via FreeIPA-users wrote:
>On 09/18/2017 05:11 PM, Marius Bjørnstad via FreeIPA-users wrote:
>> Hi,
>> 
>> When /tmp is full, it is impossible to authenticate with Kerberos. Login 
>> with password over SSH and sudo don't work. Login with ssh key works fine. 
>> Here is the output in the system log when I try to log on via SSH with 
>> password auth (this is on RHEL 6):
>> 
>> Sep 18 16:56:59 vali sshd[35157]: Set /proc/self/oom_score_adj to 0
>> Sep 18 16:56:59 vali sshd[35157]: Connection from 192.168.1.48 port 49917
>> Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache I/O 
>> operation failed XXX
>> Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache I/O 
>> operation failed XXX
>> Sep 18 16:57:04 vali sshd[35157]: Failed password for paalmbj from 
>> 192.168.1.48 port 49917 ssh2
>> Sep 18 16:57:07 vali sshd[35158]: Connection closed by 192.168.1.48
>> 
>>  From SSH I get:
>> Permission denied, please try again.
>> 
>> The problem seems to be that Kerberos can't store its credentials cache. Is 
>> this normal, and is there a way around it? Sure, ideally I should limit the 
>> space usable by each user, but that doesn't help when a given user needs to 
>> log in and fix their tmp usage.
>> 
>> Thanks,
>> Marius
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> 
>Hi,
>
>the location of the credential cache can be specified either using the
>environment variable $KRB5CCNAME or globally in /etc/krb5.conf (with the
>setting default_ccache_name, or default value FILE:/tmp/krb5cc_%{uid} if not
>specified).
>
>Please note that more recent version of freeIPA configure default_ccache_name
>= KEYRING:persistent:%{uid}
>
Just a note that setting KEYRING collection ccache requires quite new kernel
and mit krb5 (upstream 1.12 IIRC).

So the correct answer should be recent version of freeIPA on rhet7 and fedora
:-)

LS
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ipa-server-install failing at wait_for_open_ports

[Eric Scholwin via FreeIPA-users]

Foolishly, I blew up my entire 4.4 on Centos 7.4 environment and I'm trying to 
get 4.5 working on 7.4. I've been hitting the same exact problem while trying 
to install freeipa 4.5 on centos 7.4 from scratch and that's at step 6/45 
"starting directory server". The following message is what I get hung up on 
during the installation and I'm at a complete loss as to what's going on.

DEBUG wait_for_open_ports: localhost [389] timeout 300

I, like many others, had ipv6 disabled, but I've re-enabled it, and I'm still 
running into issues. 

This is what my ipaserver-install.log looks like, it fails at this samespot 
every single time:

2017-09-20T15:14:48Z DEBUG wait_for_open_ports: localhost [389] timeout 300
2017-09-20T15:19:49Z DEBUG Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
504, in start_creation
run_step(full_msg, method)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
494, in run_step
method()
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
651, in __start_instance
self.start(self.serverid)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 
627, in start
super(DsInstance, self).start(*args, **kwargs)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 
401, in start
self.service.start(instance_name, capture_output=capture_output, wait=wait)
  File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 
157, in start
instance_name, capture_output=capture_output, wait=wait)
  File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 
300, in start
self.wait_for_open_ports(self.service_instance(instance_name))
  File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 
270, in wait_for_open_ports
self.api.env.startup_timeout)
  File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1227, in 
wait_for_open_ports
raise socket.timeout("Timeout exceeded")
timeout: Timeout exceeded

2017-09-20T15:19:49Z DEBUG   [error] timeout: Timeout exceeded
2017-09-20T15:19:49Z DEBUG   File 
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute
return_value = self.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/cli.py", line 333, 
in run
cfgr.run()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 368, 
in run
self.execute()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 392, 
in execute
for _nothing in self._executor():
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, 
in __runner
exc_handler(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, 
in _handle_execute_exception
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, 
in __runner
step()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, 
in 
step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, 
in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, 
in run_generator_with_yield_from
value = gen.send(prev_value)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 658, 
in _configure
next(executor)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 434, 
in __runner
exc_handler(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 463, 
in _handle_execute_exception
self._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 521, 
in _handle_exception
self.__parent._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 518, 
in _handle_exception
super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 453, 
in _handle_exception
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 424, 
in __runner
step()
  File "/usr/lib/python2.7/site-packages/ipapython/install/core.py", line 421, 
in 
step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 81, 
in run_generator_with_yield_from
six.reraise(*exc_info)
  File "/usr/lib/python2.7/site-packages/ipapython/install/util.py", line 59, 
in run_generator_with_yield_from
value = gen.send(prev_value)
  File 

[Freeipa-users] Re: Can't log on using password when /tmp is full

[Marius Bjørnstad via FreeIPA-users]

Thanks for the replies. We have migrated most servers to RHEL7. I'll see about 
configuring the default_ccache_name on those, one way or another.

-Marius
> 20. sep. 2017 kl. 09.02 skrev Jakub Hrozek via FreeIPA-users 
> :
> 
> On Tue, Sep 19, 2017 at 04:25:21PM -0400, Simo Sorce wrote:
>> On Tue, 2017-09-19 at 20:27 +0200, Jakub Hrozek via FreeIPA-users
>> wrote:
>>> On Mon, Sep 18, 2017 at 05:11:09PM +0200, Marius Bjørnstad via
>>> FreeIPA-users wrote:
 Hi,
 
 When /tmp is full, it is impossible to authenticate with Kerberos.
 Login with password over SSH and sudo don't work. Login with ssh
 key works fine. Here is the output in the system log when I try to
 log on via SSH with password auth (this is on RHEL 6):
 
 Sep 18 16:56:59 vali sshd[35157]: Set /proc/self/oom_score_adj to 0
 Sep 18 16:56:59 vali sshd[35157]: Connection from 192.168.1.48 port
 49917
 Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
 I/O operation failed XXX
 Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
 I/O operation failed XXX
 Sep 18 16:57:04 vali sshd[35157]: Failed password for paalmbj from
 192.168.1.48 port 49917 ssh2
 Sep 18 16:57:07 vali sshd[35158]: Connection closed by 192.168.1.48
 
 From SSH I get:
 Permission denied, please try again.
 
 The problem seems to be that Kerberos can't store its credentials
 cache. Is this normal, and is there a way around it? Sure, ideally
 I should limit the space usable by each user, but that doesn't help
 when a given user needs to log in and fix their tmp usage.
>>> 
>>> Well, you need to store the credentials /somewhere/...so if the
>>> credential storage is full, the only remaining thing is to fall back
>>> to
>>> cached passwords.
>>> 
>>> Which, if they are available (through cache_credentials=True in
>>> sssd.conf) is what I'd expect to happen. If that doesn't happen,
>>> please
>>> post your sssd logs..
>>> 
>> 
>> That should happen only if we are offline, not if krb auth fails?
> 
> Yes, you're right, sorry.
> 
> (Although we've had a request to allow to run sssd in a degraded
> responder-only mode in case /var is full and the providers can't write
> into the db, I guess that's what I confused the issue with)
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: How to Setup FreeIPA Services for Mac OS X 10.12

[David Harvey via FreeIPA-users]

Thanks for your response and time Jason, much appreciated. It sounds like
you in fact have almost the opposite symptoms to me, how strange!
I did find that ldapsearch using -Y for GSSAPI was failing on Mac until I
sorted out the reverse DNS entries for my IPA servers.  The symptom was the
ldapsearch error output referring to the IP of the machine rather than the
hostname - even though I defined the host by name not IP for the command.
A host file entry got it working as a "stop gap", before I could add my
RDNS entry (I'm using Amazon route53 so the scope for me to have screwed up
the DNS is considerable).  Prior to this entry I just had the DNS bits from
"ipa dns-update-system-records --dry-run", but now I have 2x RDNS entries
added for the main names of my IPA servers (but not yet for the
ipa-ca.domain.net)

Just to confirm, are you using a bind account in order to connect with
Directory Utility?

Best,

David

On 19 September 2017 at 23:16, Jason Sherrill via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hello David,
>
> I'm experiencing similar issues with ldapsearch command, though no issues
> authenticating for logon, ssh (to linux machines), DNS updates, and
> directory services. I'm confident the issue lies with MacOS.
>
> I'm running MacOS 10.12.6 and IPA 4.5.
>
> I'll keep digging, just wanted to let you know you've been heard.
>
>
> - Jason
>
>
>
>
>
> On Tue, Sep 19, 2017 at 10:40 AM, David Harvey via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
>> Note.
>>
>> The GSSAPI attempts from the MAc side are only attempted when a binddn
>> (security -> "use authentication when connecting") account is provided.
>> Otherwise I suspect it's unable to even work out what type of GSSAPI
>> transaction to attempt..
>>
>> On 19 September 2017 at 15:19, David Harvey 
>> wrote:
>>
>>> Some edits and expansion on my previous attempt to post...
>>>
>>> Free IPA 4.4.3
>>> Mac OSX 10.12
>>>
>>> Thanks for all the hard work on this, I've been enjoying an almost
>>> functional setup for the last week but have been tearing my hair out with
>>> making GSSAPI  behave.
>>>
>>> What I have found so far using the config instructions - may be error
>>> prone now as the number of combinations tried!
>>>
>>> Anonymous bind enabled on freeipa: Works If you also specify a real
>>> user in the Directory Utility auth
>>> RootDSE only enabled on freeipa: Works If you also specify a real
>>> user in the Directory Utility auth section (not a service account)
>>> No anonymous binds: Will not play at all.
>>>
>>>
>>> Now the thing that is really throwing me, is that GSSAPI ldapsearch
>>> works just fine from the command line (using -Y GSSAPI) but  directory
>>> utility seems unable to use these credentials.
>>> I'm totally unsure if this is an OS limitation (as the login screen
>>> wouldn't have any creds until a user has typed them) or if I've managed to
>>> screw something up.
>>> From browsing my LDAP access logs it looks like only conventional binds
>>> are attempted regardless. On the mac side it did until recently still
>>> mentions GSSAPI attempts (when anonymous LDAP is disabled) although these
>>> couldn't be found int he LDAP log.  It feels like the Mac client is unable
>>> to work out how to present the krb credential due to a mapping issue or DNS
>>> discovery issue (both my IPA servers have RDNS entries).
>>>
>>> Other notable log entries on the Mac side are " failed to retrieve
>>> password for credential", and "failed to retrieve server schema". These
>>> both occur under the rootdse only ldap config.
>>>
>>> I'd like to be in a position where I can either have a very reduced
>>> access LDAP user enabled on all Mac clients, or that they can harness the
>>> host or user keytab in order to require no special LDAP credentials of
>>> their own.
>>>
>>> Most of all I suppose I want to know what should work, or be workable!
>>>
>>> Hope this makes sense, and thanks in advance,
>>>
>>> David
>>>
>>> p.s. I'm still not sure if I've managed to join this list, so subject to
>>> moderation, and I might require an explicit reply to in order to get
>>> responses!
>>>
>>
>>
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedo
>> rahosted.org
>>
>>
>
>
> --
>
> *Jason Sherrill*
> *IT Specialist*
> Deeplocal Inc. 
> mobile: 412-636-2073 <(412)%20636-2073>
> office: 412-362-0201 <(412)%20362-0201>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] LDAP OTP Failure Using Interim BIND

[Callum Guy via FreeIPA-users]

Hi All,

Since updating to CentOS 7.4/FreeIPA 4.5 (from 7.3/4.4) I have seen the
following fault.

IPA user accounts using password+OTP will authenticate *without OTP (only)*
when using an interim LDAP BIND configuration.

To clarify, I am specifically talking about Cisco ASA device, using a
password only LDAP sysaccount bind user, using the binding to authenticate
user VPN logins which all user password+OTP. Logins are only authenticated
when no OTP is present.

All other authentications (SSSD/UI) for the same user work normally and
enforce the use of the appended OTP code.

Does anyone have any ideas for debugging this situation?

Thanks,

Callum
-- 
Callum Guy
Head of Information Security
X-on

-- 



*0333 332   |  www.x-on.co.uk   |   ** 
    
   * 
X-on is a trading name of Storacall Technology Ltd a limited company 
registered in England and Wales.
Registered Office : Avaland House, 110 London Road, Apsley, Hemel 
Hempstead, Herts, HP3 9SD. Company Registration No. 2578478.
The information in this e-mail is confidential and for use by the 
addressee(s) only. If you are not the intended recipient, please notify 
X-on immediately on +44(0)333 332  and delete the
message from your computer. If you are not a named addressee you must not 
use, disclose, disseminate, distribute, copy, print or reply to this email. 
Views 
or opinions expressed by an individual
within this email may not necessarily reflect the views of X-on or its 
associated companies. Although X-on routinely screens for viruses, 
addressees should scan this email and any attachments
for viruses. X-on makes no representation or warranty as to the absence of 
viruses in this email or any attachments.

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

[Alexander Bokovoy via FreeIPA-users]

On ke, 20 syys 2017, Lachlan Musicman wrote:

Notice that many ports are only available as tcp6 listeners? Like 636
(LDAPS), 389 (LDAP), 80 (HTTP), 443 (HTTPS) and so on? This is an effect
of using v6 API that supports v4-mapped-on-v6 addresses. It makes the
code less complex and handles with the same code both IPv6 and IPv4.






Alex,

Is it sufficient to turn ipv6 on only on the IPA server (and replicas), or
do the sssd clients expect it on for the interface lo as well?

SSSD is fine with ipv4-only configuration.

--
/ Alexander Bokovoy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] IPA Vault Feature

[Ronald Wimmer via FreeIPA-users]

Hi,

I read about the vault feature in the documentation and installed the 
feature on my ipa master (ipa-kra-install). However, when I try to 
access my vault on an ipa client, I get:


ipa: INFO: trying https://ipa2.linux.mydomain.at/ipa/session/json

ipa: INFO: trying https://ipa2.linux.mydomain.at/ipa/session/json

ipa: INFO: Connection to https://ipa2.linux.mydomain.at/ipa/session/json 
failed with 401 Unauthorized>


ipa: INFO: trying https://ipa1.linux.mydomain.at/ipa/session/json

ipa: INFO: Connection to https://ipa1.linux.mydomain.at/ipa/session/json 
failed with 401 Unauthorized>


ipa: ERROR: cannot connect to 'any of the configured servers': 
https://ipa2.linux.mydomain.at/ipa/session/json, 
https://ipa1.linux.mydomain.at/ipa/session/json



What is wrong here? Am I misunderstanding the concept (centralized vault 
on ipa servers being accessable by ipa clients)?


Regards,
Ronald
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can't log on using password when /tmp is full

[Jakub Hrozek via FreeIPA-users]

On Tue, Sep 19, 2017 at 04:25:21PM -0400, Simo Sorce wrote:
> On Tue, 2017-09-19 at 20:27 +0200, Jakub Hrozek via FreeIPA-users
> wrote:
> > On Mon, Sep 18, 2017 at 05:11:09PM +0200, Marius Bjørnstad via
> > FreeIPA-users wrote:
> > > Hi,
> > > 
> > > When /tmp is full, it is impossible to authenticate with Kerberos.
> > > Login with password over SSH and sudo don't work. Login with ssh
> > > key works fine. Here is the output in the system log when I try to
> > > log on via SSH with password auth (this is on RHEL 6):
> > > 
> > > Sep 18 16:56:59 vali sshd[35157]: Set /proc/self/oom_score_adj to 0
> > > Sep 18 16:56:59 vali sshd[35157]: Connection from 192.168.1.48 port
> > > 49917
> > > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > > I/O operation failed XXX
> > > Sep 18 16:57:02 vali [sssd[krb5_child[35165]]]: Credentials cache
> > > I/O operation failed XXX
> > > Sep 18 16:57:04 vali sshd[35157]: Failed password for paalmbj from
> > > 192.168.1.48 port 49917 ssh2
> > > Sep 18 16:57:07 vali sshd[35158]: Connection closed by 192.168.1.48
> > > 
> > > From SSH I get:
> > > Permission denied, please try again.
> > > 
> > > The problem seems to be that Kerberos can't store its credentials
> > > cache. Is this normal, and is there a way around it? Sure, ideally
> > > I should limit the space usable by each user, but that doesn't help
> > > when a given user needs to log in and fix their tmp usage.
> > 
> > Well, you need to store the credentials /somewhere/...so if the
> > credential storage is full, the only remaining thing is to fall back
> > to
> > cached passwords.
> > 
> > Which, if they are available (through cache_credentials=True in
> > sssd.conf) is what I'd expect to happen. If that doesn't happen,
> > please
> > post your sssd logs..
> > 
> 
> That should happen only if we are offline, not if krb auth fails?

Yes, you're right, sorry.

(Although we've had a request to allow to run sssd in a degraded
responder-only mode in case /var is full and the providers can't write
into the db, I guess that's what I confused the issue with)
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

[Lachlan Musicman via FreeIPA-users]

On 20 September 2017 at 16:15, Lachlan Musicman  wrote:

> On 20 September 2017 at 15:54, Alexander Bokovoy 
> wrote:
>
>>
>> Ok. By the look of this commit (to 4.5):
>>>
>>> https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
>>>
>>> from this issue https://pagure.io/freeipa/issue/7083
>>>
>>> It is (or was)  the IPv6 problem.
>>>
>>> We have an
>>>
>>> [root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
>>> # Disable IPv6
>>> net.ipv6.conf.all.disable_ipv6 = 1
>>> net.ipv6.conf.ens160.disable_ipv6 = 1
>>>
>>> We don't have the 'lo' interface defined in there, but it's never been an
>>> issue.
>>>
>>> The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.
>>>
>> I'm a bit tired to repeat this multiple times but FreeIPA does require
>> IPv6 stack to be enabled in the kernel. We absolutely do. If you don't
>> use IPv6 stack, disable it on specific interfaces. However, there is a
>> practical problem with the way how glibc DNS resolver works: in default
>> configuration it always prefers IPv6 answers to IPv4 because this is
>> actually a policy of RFC3484. As result, if you have ::1 in /etc/hosts,
>> it will be returned first. If you don't have ::1 on any of your
>> interfaces ('lo' is a typical one), then apps cannot contact ::1
>> (localhost) even if those apps that use IPv6 bind to all interfaces.
>>
>> FreeIPA uses modern APIs provided by glibc to listen on both IPv6 and
>> IPv4. It simply means that FreeIPA servers bind to IPv6 addresses (on
>> all interfaces or on a specific one, if needed) and treat IPv4 as mapped
>> ones because IPv6 and IPv4 share the same port space on the same
>> machine. This works transparently thanks to glibc and is a recommended
>> way to write networking applications. See man ipv6(7) for details.
>>
>> Here is how it looks on a real system, for TCP listeners:
>>
>> # netstat -nltp
>> Active Internet connections (only servers)
>> Proto Recv-Q Send-Q Local Address   Foreign Address
>>  State   PID/Program nametcp0  0 127.0.0.1:953
>>  0.0.0.0:*   LISTEN  13361/named-pkcs11  tcp
>> 0  0 0.0.0.0:445 0.0.0.0:*   LISTEN
>> 13760/smbd  tcp0  0 0.0.0.0:49152   0.0.0.0:*
>>  LISTEN  13765/smbd  tcp0  0
>> 0.0.0.0:135 0.0.0.0:*   LISTEN  13763/smbd
>> tcp0  0 0.0.0.0:139 0.0.0.0:*
>>LISTEN  13760/smbd  tcp0  0 0.0.0.0:749
>>0.0.0.0:*   LISTEN  13351/kadmind   tcp
>>   0  0 0.0.0.0:464 0.0.0.0:*   LISTEN
>> 13351/kadmind   tcp0  0 192.168.100.233:53  0.0.0.0:*
>>  LISTEN  13361/named-pkcs11  tcp0  0
>> 127.0.0.1:530.0.0.0:*   LISTEN
>> 13361/named-pkcs11  tcp0  0 0.0.0.0:22  0.0.0.0:*
>>  LISTEN  2838/sshd   tcp0  0
>> 0.0.0.0:88  0.0.0.0:*   LISTEN
>> 13345/krb5kdc   tcp6   0  0 ::1:953 :::*
>> LISTEN  13361/named-pkcs11  tcp6   0  0 :::8443
>>  :::*LISTEN  13603/java  tcp6
>>  0  0 :::443  :::*LISTEN
>> 13379/httpd tcp6   0  0 :::636  :::*
>> LISTEN  13296/ns-slapd  tcp6   0  0 :::445
>> :::*LISTEN  13760/smbd  tcp6
>>0  0 :::49152:::*LISTEN
>> 13765/smbd  tcp6   0  0 :::9090 :::*
>> LISTEN  1/systemd   tcp6   0  0
>> 127.0.0.1:8005  :::*LISTEN  13603/java
>> tcp6   0  0 :::389  :::*
>> LISTEN  13296/ns-slapd  tcp6   0  0 :::135
>> :::*LISTEN  13763/smbd  tcp6   0  0
>> 127.0.0.1:8009  :::*LISTEN  13603/java
>> tcp6   0  0 :::139  :::*
>> LISTEN  13760/smbd  tcp6   0  0 :::749
>> :::*LISTEN  13351/kadmind   tcp6   0  0
>> :::8080 :::*LISTEN  13603/java
>> tcp6   0  0 :::80   :::*
>> LISTEN  13379/httpd tcp6   0  0 :::464
>> :::*LISTEN  13351/kadmind   tcp6   0  0
>> :::53   :::*LISTEN
>> 13361/named-pkcs11  tcp6   0  0 :::22   :::*
>> LISTEN  2838/sshd   tcp6   0  0 :::88
>>  :::*LISTEN  13345/krb5kdc
>> Notice that many ports are only available as tcp6 

[Freeipa-users] Re: 7.4 upgrade fails with timeout exceeded

[Lachlan Musicman via FreeIPA-users]

On 20 September 2017 at 15:54, Alexander Bokovoy 
wrote:

>
> Ok. By the look of this commit (to 4.5):
>>
>> https://pagure.io/freeipa/c/bdf9a34dffdf4d7925208e5df9f69e3927b88858
>>
>> from this issue https://pagure.io/freeipa/issue/7083
>>
>> It is (or was)  the IPv6 problem.
>>
>> We have an
>>
>> [root@linuxidm ~]# cat /etc/sysctl.d/ipv6.conf
>> # Disable IPv6
>> net.ipv6.conf.all.disable_ipv6 = 1
>> net.ipv6.conf.ens160.disable_ipv6 = 1
>>
>> We don't have the 'lo' interface defined in there, but it's never been an
>> issue.
>>
>> The /etc/hosts entry for ::1 must have thrown ipa-server-upgrade.
>>
> I'm a bit tired to repeat this multiple times but FreeIPA does require
> IPv6 stack to be enabled in the kernel. We absolutely do. If you don't
> use IPv6 stack, disable it on specific interfaces. However, there is a
> practical problem with the way how glibc DNS resolver works: in default
> configuration it always prefers IPv6 answers to IPv4 because this is
> actually a policy of RFC3484. As result, if you have ::1 in /etc/hosts,
> it will be returned first. If you don't have ::1 on any of your
> interfaces ('lo' is a typical one), then apps cannot contact ::1
> (localhost) even if those apps that use IPv6 bind to all interfaces.
>
> FreeIPA uses modern APIs provided by glibc to listen on both IPv6 and
> IPv4. It simply means that FreeIPA servers bind to IPv6 addresses (on
> all interfaces or on a specific one, if needed) and treat IPv4 as mapped
> ones because IPv6 and IPv4 share the same port space on the same
> machine. This works transparently thanks to glibc and is a recommended
> way to write networking applications. See man ipv6(7) for details.
>
> Here is how it looks on a real system, for TCP listeners:
>
> # netstat -nltp
> Active Internet connections (only servers)
> Proto Recv-Q Send-Q Local Address   Foreign Address State
>  PID/Program nametcp0  0 127.0.0.1:953
>  0.0.0.0:*   LISTEN  13361/named-pkcs11  tcp0
>   0 0.0.0.0:445 0.0.0.0:*   LISTEN
> 13760/smbd  tcp0  0 0.0.0.0:49152   0.0.0.0:*
>  LISTEN  13765/smbd  tcp0  0
> 0.0.0.0:135 0.0.0.0:*   LISTEN  13763/smbd
>   tcp0  0 0.0.0.0:139 0.0.0.0:*
>  LISTEN  13760/smbd  tcp0  0 0.0.0.0:749
>0.0.0.0:*   LISTEN  13351/kadmind   tcp0
> 0 0.0.0.0:464 0.0.0.0:*   LISTEN
> 13351/kadmind   tcp0  0 192.168.100.233:53  0.0.0.0:*
>  LISTEN  13361/named-pkcs11  tcp0  0
> 127.0.0.1:530.0.0.0:*   LISTEN
> 13361/named-pkcs11  tcp0  0 0.0.0.0:22  0.0.0.0:*
>  LISTEN  2838/sshd   tcp0  0
> 0.0.0.0:88  0.0.0.0:*   LISTEN
> 13345/krb5kdc   tcp6   0  0 ::1:953 :::*
> LISTEN  13361/named-pkcs11  tcp6   0  0 :::8443
>  :::*LISTEN  13603/java  tcp6
>  0  0 :::443  :::*LISTEN
> 13379/httpd tcp6   0  0 :::636  :::*
> LISTEN  13296/ns-slapd  tcp6   0  0 :::445
> :::*LISTEN  13760/smbd  tcp6
>0  0 :::49152:::*LISTEN
> 13765/smbd  tcp6   0  0 :::9090 :::*
> LISTEN  1/systemd   tcp6   0  0
> 127.0.0.1:8005  :::*LISTEN  13603/java
>   tcp6   0  0 :::389  :::*
> LISTEN  13296/ns-slapd  tcp6   0  0 :::135
> :::*LISTEN  13763/smbd  tcp6   0  0
> 127.0.0.1:8009  :::*LISTEN  13603/java
>   tcp6   0  0 :::139  :::*
> LISTEN  13760/smbd  tcp6   0  0 :::749
> :::*LISTEN  13351/kadmind   tcp6   0  0
> :::8080 :::*LISTEN  13603/java
> tcp6   0  0 :::80   :::*
> LISTEN  13379/httpd tcp6   0  0 :::464
> :::*LISTEN  13351/kadmind   tcp6   0  0
> :::53   :::*LISTEN
> 13361/named-pkcs11  tcp6   0  0 :::22   :::*
> LISTEN  2838/sshd   tcp6   0  0 :::88
>  :::*LISTEN  13345/krb5kdc
> Notice that many ports are only available as tcp6 listeners? Like 636
> (LDAPS), 389 (LDAP), 80 (HTTP), 443 (HTTPS) and so on? This is an effect
> of using v6 API that supports v4-mapped-on-v6 addresses. It makes the
> code less