ssh ProxyCommand in ipa-client causes crash of x2goclient
by Kees Bakker
Hey,
With x2go [1] you can start a remote desktop. Going from UNIX (client) to UNIX (server)
it will use SSH behinds the scenes.
However, on a IPA client the x2goclient command fails with a segfault (somewhere in a ssh library).
This is caused by the modified /etc/ssh/ssh_config. More specifically this
ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h
When you disable this line the x2go connection succeeds.
[1] https://wiki.x2go.org/doku.php
--
Kees
4 years, 1 month
Multiple HBAC rules in one Apache config
by Ronald Wimmer
Hi,
is there a way to use multiple HBAC rules in the same "Require
pam-account" line in on and the same Apache config?
Something like
Require pam-account hbacA|hbacB
Cheers,
Ronald
4 years, 1 month
Re: group management on freeipa clients
by Kevin Vasko
So. this is an interesting read thanks for that.
But just a FYI to the OP, if you are using any Ubuntu 18.04 clients (i haven’t tried it with Fedora/CentOS) there is an issue with not having local docker groups on the system.
What ends up happening is on a boot, docker services try starting up, but look for a local docker group when they do. If there is no docker group the service times out. When the machine does finally boot up, DNS resolution for some reason is broken. Networking works fine (e.g can ping 8.8.8.8 or any local ip). But without DNS resolution the machine won’t properly find the IPA server and won’t allow users to login.
Docker made this service change from 16.04 to 18.04.
Here I detailed how I determined what the issue was. I put in another ticket with this information but was told it wasn’t an issue with docker.
https://github.com/docker/libnetwork/issues/2335
-Kevin
> On Oct 24, 2019, at 6:18 PM, Simo Sorce via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> wrote:
>
> I strongly recommend reading this article:
> https://www.projectatomic.io/blog/2015/08/why-we-dont-let-non-root-users-...
>
> And based on it, I would a) reconsider if using sudo is not a better
> idea, b) recommend, if possible, to create the docker group locally and
> add users explicitly on the specific machines.
>
> I would fallback to a global docker group that basically gives root to
> any user on any machine with docker installed they have access to only
> as a least resort.
>
> Simo.
>
>> On Wed, 2019-10-23 at 19:07 +0000, Jason Dunham via FreeIPA-users
>> wrote:
>> Hi I'm trying to figure out the best practice for groups on my client servers.
>> I have several computation workstation hosts that have been added as freeipa clients, and several engineers who want to run docker on them
>> Members of the 'docker' group (gid=999 on some machines, for example) can run docker without needing sudo, which is what I want to roll out to all machines. Ideally this would be managed from freeipa with LDAP groups, and so anyone in the 'engineers' group should also be a member of the 'docker' group.
>> When I create a 'docker' group on freeIPA it will have some other gid and the client sees that.
>> Should I just delete the original docker group from my hosts and let it get it from ldap, or should I go into /etc/group and change the gid to the one that matches the right ldap gid, or preferably something easier than that?
>> _______________________________________________
>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
> --
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
4 years, 1 month
group management on freeipa clients
by Jason Dunham
Hi I'm trying to figure out the best practice for groups on my client servers.
I have several computation workstation hosts that have been added as freeipa clients, and several engineers who want to run docker on them
Members of the 'docker' group (gid=999 on some machines, for example) can run docker without needing sudo, which is what I want to roll out to all machines. Ideally this would be managed from freeipa with LDAP groups, and so anyone in the 'engineers' group should also be a member of the 'docker' group.
When I create a 'docker' group on freeIPA it will have some other gid and the client sees that.
Should I just delete the original docker group from my hosts and let it get it from ldap, or should I go into /etc/group and change the gid to the one that matches the right ldap gid, or preferably something easier than that?
4 years, 1 month
valid hostname?
by Amos
When enrolling a host, an error was presented:
root : INFO Joining realm failed: RPC failed at server. invalid
'hostname': invalid domain-name: only letters, numbers, '-' are allowed.
DNS label may not start or end with '-'
Where does this error originate from? Is it truly impossible to allow
hosts with "_" in their name?
Amos
4 years, 1 month
ansbile-freeipa client install
by Andrew Meyer
Hello I have setup ansible to use install freeipa client on my CentOS 7/8 machines. I am
able to get the packages installed however when it goes through the configuration I am
getting the following:
TASK [ipaclient : Install - Ensure that IPA client packages are installed]
******************************************************************************************************************************************************************
ok: [10.150.10.15]
TASK [ipaclient : Install - Set ipaclient_servers]
******************************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Set ipaclient_servers from cluster inventory]
*******************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Check that either principal or keytab is set]
*******************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Set default principal if no keytab is given]
********************************************************************************************************************************************************************
ok: [10.150.10.15]
TASK [ipaclient : Install - IPA client test]
************************************************************************************************************************************************************************************************
ok: [10.150.10.15]
TASK [ipaclient : Install - Cleanup leftover ccache]
****************************************************************************************************************************************************************************************
ok: [10.150.10.15]
TASK [ipaclient : Install - Configure NTP]
**************************************************************************************************************************************************************************************************
changed: [10.150.10.15]
TASK [ipaclient : Install - Disable One-Time Password for on_master]
************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Test if IPA client has working krb5.keytab]
*********************************************************************************************************************************************************************
ok: [10.150.10.15]
TASK [ipaclient : Install - Disable One-Time Password for client with working krb5.keytab]
**************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Keytab or password is required for otp]
*************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Get One-Time Password for client enrollment]
********************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Report error for OTP generation]
********************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Store the previously obtained OTP]
******************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Check if principal and keytab are set]
**************************************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Install - Check if one of password or keytabs are set]
********************************************************************************************************************************************************************
fatal: [10.150.10.15]: FAILED! => {"changed": false, "msg":
"At least one of password or keytabs must be specified"}
TASK [ipaclient : Install - Restore original admin password if overwritten by OTP]
**********************************************************************************************************************************************************
skipping: [10.150.10.15]
TASK [ipaclient : Cleanup leftover ccache]
**************************************************************************************************************************************************************************************************
ok: [10.150.10.15]
PLAY RECAP
**********************************************************************************************************************************************************************************************************************************
10.150.10.15 : ok=10 changed=1 unreachable=0 failed=1 skipped=11
rescued=0 ignored=0
I am not sure that I am using the correct variables in ansible-vault for the keytabs:
ipaadmin_password1: password1234
ipadm_password1: password1234
ipaserver_realm1: TEST.EXAMPLE
ipaserver_domain1: test.example
ipaclient_principal1: admin
ipaclient_password1: password1234
Should the variable be 'ipaadmin_principal1:' ? Also should this be the
password?
And I want to skip installing the ntp client would this be the correct way to do it?
ansible-playbook --ask-vault-pass --extra-vars 'ansible/passwd.yml'
ansible-freeipa/playbooks/install-client.yml --limit=10.150.10.15 --user=user123 -e
"ipaclient_no_ntp=no"
4 years, 1 month
using SPAKE
by Charles Hedrick
I’d like to avoid having to use a second cache to armor 2FA requests. My impression was that SPAKE was supposed to fix this. I just installed a new kdc (replica of an old one) in Centos 8. It understands SPAKE, offering it as preauthebtication for normal users. But a user with 2FA is not offered SPAKE preach. I still have to use FAST.
Have I misunderstood, or is extra configuration needed?
4 years, 1 month
is it possible to enable constrained delegation for only some users?
by Charles Hedrick
We have kerberos everywhere, and use it for access to NFS home directories.
So what do we do about cron jobs? We have a solution, but it involves custom code that impersonates the KDC. I’d like to do someone more standard.
Constained delegation seems like a possibility. But I’d need to be able to say “allow cron to get credentials for NFS for a specific group of users.” Since all of our systems run cron, I don’t want to allow any system to be able to get an NFS credential for any user. That would let root on any system see anyone’s files. So the user has to authorize it. Presumably if the user runs his own desktop, he’s willing to allow it to get credentials for himself. But I wouldn’t trust his machine to be able to get mine.
The constrained delegation mechanism seems to handle this, except that I don’t see a way to constrain it to specific users. Am I missing something?
4 years, 1 month
Retrieve private key from CA chain
by Sam Klein
Using certutil, I'm able to extract my localhost CA using this command.
certutils -L -d dbm:/etc/ipa/nssdb -a -n 'Local IPA host'
However, I need a signing key to create a private key. Is there a method to extract a private key that signed my localhost CA from the endpoint, or does this key exist on my server?
Thank you.
4 years, 1 month
Re: ns-slapd hangs several times a day
by Jared Ledvina
//Keeping the freeipa-users list included
Hi Sylvain,
Ah shucks. For the debug info packages, you might be able to leverage the packages available on https://dl.fedoraproject.org/pub/epel/ but, someone else on this list might know more.
The only other idea that comes to mind is what was discussed on https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Specifically, in your 'cn=config' see if nsslapd-enable-nunc-stans is set to on, if it is, try using the ldapmodify in the above comment to disable it. For context, that defaults to off as a result of https://bugzilla.redhat.com/show_bug.cgi?id=1614501
Hope this helps,
Jared
On Mon, Oct 21, 2019, at 5:31 AM, Sylvain Coutant wrote:
> Jared,
>
> Thanks for your message. To be honest, I would have expected this to be a network issue at first. All the symptoms are there. But tcpdump tells me that things are ok ...
>
> For the debuginfo, I already had a look but was unable to find the right packages:
>
> yum search --enablerepo=epel-debuginfo 389-ds
> Loaded plugins: fastestmirror
> Loading mirror speeds from cached hostfile
> * base: centos.mirrors.proxad.net
> * epel: mirrors.coreix.net
> * epel-debuginfo: mirrors.coreix.net
> * extras: centos.mirrors.proxad.net
> * updates: centos.mirrors.proxad.net
> ==================================================================================================================================================================================================================================== N/S matched: 389-ds =====================================================================================================================================================================================================================================
> 389-dsgw-debuginfo.x86_64 : Debug information for package 389-dsgw
> 389-ds.noarch : 389 Directory, Administration, and Console Suite
> 389-ds-base.x86_64 : 389 Directory Server (base)
> 389-ds-base-devel.x86_64 : Development libraries for 389 Directory Server
> 389-ds-base-libs.x86_64 : Core libraries for 389 Directory Server
> 389-ds-base-snmp.x86_64 : SNMP Agent for 389 Directory Server
> 389-ds-console.noarch : 389 Directory Server Management Console
> 389-ds-console-doc.noarch : Web docs for 389 Directory Server Management Console
> 389-dsgw.x86_64 : 389 Directory Server Gateway (dsgw)
>
> There's no 389-ds-base-debuginfo available. I'm probably missing something ...
>
> Like always, the cluster hanged during the nightly backup. The node running the backup was dead. After restarting it, I tried to disable retroCL triming as per https://bugzilla.redhat.com/show_bug.cgi?id=1751295, but still had a hang during resync. I enabled a few more logs in ds, but at first it doesn't look much helpful right now except that it stops logging anything (including housekeeping stuff) when stale.
>
>
> /Sylvain.
>
>
>
>
> Le lun. 21 oct. 2019 à 06:00, Jared Ledvina <jared(a)techsmix.net> a écrit :
>> __
>> Hi Sylvain,
>>
>> I believe we had a similar issue in our configuration. I can dig in more tomorrow but, we had deadlocks with the retroCL plugin.
>>
>> If you follow the steps outlined on this page, https://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debug_hangs to get a stack trace, I can try to see if you're hitting the same thing.
>>
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1751295 for some more details on the issue.
>>
>> Hope that helps,
>> Jared
>>
>> On Sun, Oct 20, 2019, at 3:55 PM, Sylvain Coutant via FreeIPA-users wrote:
>>> Hello gurus,
>>>
>>> We are running a 3 nodes FreeIPA cluster for some time without major trouble. One server may stale from time to time, without real trouble to restart it.
>>>
>>> A few days ago, we had to migrate the VMs between two clouds (disk image copied from one to the other). They have been renumbered from old to new IPv4 address space. Not that easy, but we finally got it done with all DNS entries in sync. Yet, since the migration, ns-slapd process hangs randomly way more often than before (went from once every few months to several times a day) and is especially hard to restart on any node.
>>>
>>> While starting up, the netstat output is like:
>>>
>>> Active Internet connections (w/o servers)
>>> Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
>>> tcp6 184527 0 10.217.151.3:389 10.217.151.2:52314 ESTABLISHED 29948/ns-slapd
>>>
>>> Netstat and tcpdump show it processes very slowly the recvq (sometimes like 79 bytes per 1-2 seconds). At some point it just stops processing it and hangs (only kill -9 works to take it down). When stale, strace shows the process loops only on :
>>>
>>> getpeername(8, 0x7ffe62c49fd0, 0x7ffe62c49f94) = -1 ENOTCONN (Transport endpoint is not connected)
>>> poll([{fd=50, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=9, events=POLLIN}, {fd=117, events=POLLIN}, {fd=116, events=POLLIN}, {fd=115, events=POLLIN}, {fd=114, events=POLLIN}, {fd=89, events=POLLIN}, {fd=85, events=POLLIN}, {fd=83, events=POLLIN}, {fd=82, events=POLLIN}, {fd=81, events=POLLIN}, {fd=80, events=POLLIN}, {fd=79, events=POLLIN}, {fd=78, events=POLLIN}, {fd=77, events=POLLIN}, {fd=76, events=POLLIN}, {fd=67, events=POLLIN}, {fd=72, events=POLLIN}, {fd=69, events=POLLIN}, {fd=64, events=POLLIN}, {fd=66, events=POLLIN}], 23, 250) = 0 (Timeout)
>>>
>>> If it can go through startup replication, one of the server will hang a little bit later, freezing the whole cluster. Forcing us to restart the faulty node to unlock things.
>>>
>>> When stale, the dirsrv access log only contains entries like:
>>> [20/Oct/2019:17:52:46.950029525 +0100] conn=86 fd=131 slot=131 connection from 10.217.151.4 to 10.217.151.4
>>> [20/Oct/2019:17:52:51.280412883 +0100] conn=87 fd=132 slot=132 SSL connection from 10.217.151.10 to 10.217.151.4
>>> [20/Oct/2019:17:52:54.956204031 +0100] conn=88 fd=133 slot=133 connection from 10.217.151.4 to 10.217.151.4
>>> [20/Oct/2019:17:53:04.966542441 +0100] conn=89 fd=134 slot=134 connection from 10.217.151.2 to 10.217.151.4
>>> [20/Oct/2019:17:53:22.659053020 +0100] conn=90 fd=135 slot=135 SSL connection from 10.217.151.10 to 10.217.151.4
>>> [20/Oct/2019:17:53:51.006707605 +0100] conn=91 fd=136 slot=136 connection from 10.217.151.4 to 10.217.151.4
>>> [20/Oct/2019:17:53:54.514162543 +0100] conn=92 fd=137 slot=137 SSL connection from 10.217.151.10 to 10.217.151.4
>>> [20/Oct/2019:17:53:59.011602776 +0100] conn=93 fd=138 slot=138 connection from 10.217.151.3 to 10.217.151.4
>>> [20/Oct/2019:17:54:09.019296900 +0100] conn=94 fd=139 slot=139 connection from 10.217.151.4 to 10.217.151.4
>>>
>>> And netstat lists 10s of accepted network connections that are stale like :
>>> tcp6 286 0 10.217.151.4:389 10.217.151.10:32512 ESTABLISHED 29948/ns-slapd
>>>
>>>
>>> The underlying network seams clean and uses jumbo frames. tcpdump and ping show 0 packet loss and no retransmit. Being afraid it could be a jumbo frame issue, mtu was even forced down to 1500. Without success.
>>>
>>> Entropy seems fine as well :
>>> # cat /proc/sys/kernel/random/entropy_avail
>>> 3138
>>>
>>> Running version on all servers:
>>> ipa-client-4.6.5-11.el7.centos.x86_64
>>> ipa-client-common-4.6.5-11.el7.centos.noarch
>>> ipa-common-4.6.5-11.el7.centos.noarch
>>> ipa-server-4.6.5-11.el7.centos.x86_64
>>> ipa-server-common-4.6.5-11.el7.centos.noarch
>>> ipa-server-dns-4.6.5-11.el7.centos.noarch
>>>
>>>
>>> I'd happily listen to any hint regarding this critical problem.
>>>
>>> /Sylvain.
>>> _______________________________________________
>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>
>>
4 years, 1 month
