When I try to perform command after command kinit admin:
ipa group-remove-member group --users=test
I get next:
member user: test: Insufficient access: Insufficient 'write' privilege to
the 'member' attribute of entry...
How can I fix it?
A machine has just been installed with a minimal RHEL8.1 distro.
Note that in /etc/login.defs there is the line
Installing the server from a shell works fine:
$ ipa-server-install <options>
However, installing the server through Ansible (2.9.6) from
another host does *not* work.
Snippet from the Ansible script:
- name: Install ipa-server
/usr/bin/umask 022 && /usr/bin/ipa-server-install <options>
The installer complains about the umask being 0077 and that it
should be 0022. Removing the UMASK line from login.defs fixes the
immediate problem. There is really no Ansible configuration
1) Is there a good way to fix this without opening up system umask?
2) If I comment out the UMASK line from login.defs for the
installation and reactivate it afterwards, will that cause
(I think this is about access rights to the certificates of the
Dominik ^_^ ^_^
On Thu, Dec 31, 2020 at 07:43:48AM +0000, Angus Clarke via FreeIPA-users wrote:
> Forward and reverse lookups use the resolver library which is configured through /etc/nsswitch.conf
> As long as files is listed before dns then you should be good:
> $ grep ^hosts: /etc/nsswitch.conf
> hosts: files dns myhostname
Actually, with the --setup-dns option it doesn't. The installer
really does a DNS setup then. But without --setup-dns it
runs into a 30 second timeout, complains a bit but continues
Dominik ^_^ ^_^
we need to install ipa-server on a box running RHEL8, say
server.foo.bar.baz, 192.168.123.45. ipa-server-install needs
working name resolution for that host, and as there is no other
machine installed yet, this server must run named to provide it.
Is there some working sample configuration for named (RHEL8 config
style) that suffices to install ipa-server (using the --setup-dns
Dominik ^_^ ^_^
1. How can I get machine that is joined as ipa-client recieve a kerberos
ticket for a specific user without storing a password or having to
I want to replace this, manual systemd tricker that I currently run:
ExecStart=/usr/bin/bash -c "echo -n "secretpass" | kinit -r 14d -l 7d
I need the kerberos ticket because I use it to autenticate with
smbclient -k to a samba serve to get access to files.
2. How can I make a system user like the admin account only without
admin rights, but still available with id and getent tools. I need
machine account that holds a kerberos ticket. A normal user shows up
everywhere through LDAP, the admin user does not but is still available
in sssd and other integrations.
Jelle de Jong
I’ve been running a number of macs bound to FreeIPA for years now. The biggest nuisance is that I haven’t found a way to make home directory when one doesn’t exist.
Without a home directory, a users logs in, the beachball spins forever and the user never gets a desktop because there is no user home directory.
"createhomedir -c -a" functions (on most systems), but I’d rather not run this in cron.
Has anyone found the PAM secret to have this function like mkhomedir on a CentOS host?
grant@outhouse:~[20201213-6:51][#1003]$ authconfig --test | grep mkhome
pam_mkhomedir or pam_oddjob_mkhomedir is enabled (umask=0077)
I wish there were an authconfig on os-x
This e-mail and any attachments are intended only for use by the addressee(s) named herein and may contain confidential information. If you are not the intended recipient of this e-mail, you are hereby notified any dissemination, distribution or copying of this email and any attachments is strictly prohibited. If you receive this email in error, please immediately notify the sender by return email and permanently delete the original, any copy and any printout thereof. The integrity and security of e-mail cannot be guaranteed.
I'm experiencing a LDAP client problem on CentOS 7 after upgrade of FreeIPA server from CentOS 8.2 (FreeIPA 4.8.4) to 8.3 (FreeIPA 4.8.7).
Here is what I was able to find. During login, nslcd on client performs LDAP bind using credentials provided by user. Here are the nslcd debug logs:
against 4.8.4 server, working:
nslcd: [8b4567] <authc="myuser"> DEBUG: ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***") (uri="ldap://ipa2.my.org")
nslcd: [8b4567] <authc="myuser"> DEBUG: ldap_result(): uid=myuser,cn=users,cn=compat,dc=my,dc=org
nslcd: [8b4567] <authc="myuser"> DEBUG: ldap_unbind()
nslcd: [8b4567] <authc="myuser"> DEBUG: bind successful
against 4.8.7 server, not working:
nslcd: [b0dc51] <authc="myuser"> DEBUG: ldap_start_tls_s()
nslcd: [b0dc51] <authc="myuser"> DEBUG: ldap_simple_bind_s("uid=myuser,cn=users,cn=compat,dc=my,dc=org","***") (uri="ldap://ipa3.my.org")
nslcd: [b0dc51] <authc="myuser"> ldap_result() failed: No such object
nslcd: [b0dc51] <authc="myuser"> uid=myuser,cn=users,cn=compat,dc=my,dc=org: lookup failed: No such object
nslcd: [b0dc51] <authc="myuser"> DEBUG: ldap_unbind()
I attempted to replicate what nslcd does using ldapsearch, and I could not find any difference between output from 4.8.4 and 4.8.7. I can bind as my user and run queries. I also checked the changelog between these server versions and could not find anything suspicious. Any suggestions how to deal with this? Thanks.
We have our NFS servers kerberized which requires a ticket to be able to access the NFS share. We also have a GPU cluster where people get to launch docker containers to complete work. Unfortunately, within the container users can’t access the NFS share even though its mapped on the host machine and in the container because they don’t have a ticket within the container.
So what are my options to deal with this? Would building a container and when it starts up, automatically enroll itself into FreeIPA be the best solution? As a test I tried to enroll the container in one of our test containers and freeipa-client-install complained that pid 1 wasn’t being ran by systemd, not quite sure how to get around that. However even if this was accomplished could enrolling 100s or 1000s of containers cause an issue for freeIPA?Most of these would be fairly short lived (few days to weeks). At that point I would need to go manually cleanup all of the enrolled machines.
The other and less optimal solution would be to use a non kerberized NFS share, pass through the uid/gid from the host, but with this solution users would know their own UID/GID in the container but wouldn’t know who owns what in the container because they would have nothing tell them in the container what UID/GID is associated with what account so it might get confusing.
I’m really just looking for any suggestions on what other people have done. I’m not even sure if what I’m doing is the right approach at all and I should be doing something totally different. Are there any other solutions/suggestions that people have used to operate with FreeIPA along with docker containers?
To create a nice new proper domain in CentOS8 (with a new name and so), I use
"ipa migrate-ds" on a fresh installed Centos8 server, to retrieve entries from
my current domain in CentOS7 :
ipa migrate-ds ldap://my_current_server:389
But "ipa migrate-ds" fails with this message for each user :
xxx: missing attribute "sn" required by object class "organizationalPerson"
with a final :
No users/groups were migrated from ldap://...:389
I try with and without --with-compat option, and with ipa-compat-manage enabled
But when I look at ldap entries on the server in production, I see however a sn
record (containing the last name) for each user. So where is the bug ?
Jacquelin Charbonnel - (+33)2 4173 5397
CNRS Mathrice/LAREMA - Campus universitaire d'Angers