Re: [Freeipa-users] replica creation problems
On 04/14/2017 03:04 AM, Florence Blanc-Renaud wrote: Hi Josh, I did not try this type of setup myself, but I think the issue comes from missing root certificates. I would try to run $ ipa-cacert-manage --install $ ipa-certupdate on the master. This command will install issuer B certificate as a trusted CA on the master, thus allowing communications with services (eg LDAP on replica) using certificates delivered by issuer B. You may find more information in /var/log/dirsrv/slapd-DOMAINNAME/access and errors files. You can also check if the root certificates are installed in each LDAP server's NSS DB: $ certutil -L -d /etc/dirsrv/slapd-DOMAINNAME You should find issuer A and issuer B certs with CT,C,C trust flags on each machine. HTH, Flo. Hello Florence, Your explanation is correct. After # ipa-cacert-manage install # kinit admin # ipa-certupdate and staring replica prepared over. replica configuration completed with no errors. However I noticed strange ipa-replica-manage behavior: # ipa-replica-manage del replica_host_name Connection to 'replica_host_name' failed: Insufficient access: Invalid credentials Unable to delete replica 'replica_host_name' # Does anyone know what is missing here? Josh. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa and SELinux Users
On Fri, 14 Apr 2017, Justin Stephenson wrote: Maybe this is what you are looking for? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/mapping-selinux.html Also make sure to use POSIX group for mapping assignment because ipausers is non-POSIX group. -Justin On 04/14/2017 11:29 AM, Alex Thomas wrote: I am sure this is hiding in the docs somewhere but my google-fu is failing. Since I am running a network with Centos 7 servers and Fedora 25 clients, I would like to set FreeIPA so that users in ipauser are given SELinux role of user_u, and those in the admin group are given sysadm_u. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa and SELinux Users
Maybe this is what you are looking for? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/mapping-selinux.html -Justin On 04/14/2017 11:29 AM, Alex Thomas wrote: I am sure this is hiding in the docs somewhere but my google-fu is failing. Since I am running a network with Centos 7 servers and Fedora 25 clients, I would like to set FreeIPA so that users in ipauser are given SELinux role of user_u, and those in the admin group are given sysadm_u. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Freeipa and SELinux Users
I am sure this is hiding in the docs somewhere but my google-fu is failing. Since I am running a network with Centos 7 servers and Fedora 25 clients, I would like to set FreeIPA so that users in ipauser are given SELinux role of user_u, and those in the admin group are given sysadm_u. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
Here are my findings. The problem seems to be related to mkhomedir. By default my homedir looks like /home/%d/%u. In this case, when a user logs in for the first time /home/%d gets created and the %u part is missing. If I create it manually everything works fine. If i set override_homedir to /home/%u in the testclients sssd (nss section) settings the directory gets created and almost everything works fine. On the first login I get a "Could not chdir to home directory /home/myuser: No such file or directory" - the directory seems to get created to late. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
I got a little further. Now the share also automounts on the client with sec set to krb5 but the user still gets a "Permission denied" and cannot access his home directory. Can it be related to the fact that the user comes from AD? (Unfortunately, I cannot test with a native IPA user due to another issue.) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem automounting home shares
On 2017-04-13 14:24, Ronald Wimmer wrote:
> [...]
> It was my own fault. I somehow messed up the /etc/krb5.keytab on the
> testclient. After correcting it everything works like a charm.
No. It was notI was mistaken. The problem is:
- sec=sys
when I set sec=sys, the share gets automounted and the directory gets
created
with the right permissions but the user gets a "Permission denied"
fore some reason
- sec=krb5
the share does not even get automounted
sec=krb5p:
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
looking up /home
Apr 14 13:30:06 testclient automount[17792]: lookup_mount: lookup(sss):
/home -> -fstype=nfs4,rw,sec=krb5p ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
expanded entry: -fstype=nfs4,rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
gathered options: fstype=nfs4,rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
dequote("ipanfs.linux.mydomain.at:/homeshare") ->
ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: parse_mount: parse(sun):
core of entry: options=fstype=nfs4,rw,sec=krb5p,
loc=ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: sun_mount: parse(sun):
mounting root /home, mountpoint /home, what
ipanfs.linux.mydomain.at:/homeshare, fstype nfs4, options rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
root=/home name=/home what=ipanfs.linux.mydomain.at:/homeshare,
fstype=nfs4, options=rw,sec=krb5p
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
nfs options="rw,sec=krb5p", nobind=0, nosymlink=0, ro=0
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: called with
host ipanfs.linux.mydomain.at(10.66.39.164) proto 6 version 0x40
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: nfs v4 rpc
ping time: 0.000265
Apr 14 13:30:06 testclient automount[17792]: get_nfs_info: host
ipanfs.linux.mydomain.at cost 265 weight 0
Apr 14 13:30:06 testclient automount[17792]: prune_host_list: selected
subset of hosts that support NFS4 over TCP
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mkdir_path /home
Apr 14 13:30:06 testclient automount[17792]: mount_mount: mount(nfs):
calling mount -t nfs4 -s -o rw,sec=krb5p
ipanfs.linux.mydomain.at:/homeshare /home
Apr 14 13:30:06 testclient automount[17792]: spawn_mount: mtab link
detected, passing -n to mount
Apr 14 13:30:06 testclient gssproxy: gssproxy[889]: (OID: { 1 2 840
113554 1 2 2 }) Unspecified GSS failure. Minor code may provide more
information, No credentials cache found
Apr 14 13:30:06 testclient automount[17792]: >> mount.nfs4: access
denied by server while mounting ipanfs.linux.mydomain.at:/homeshare
Apr 14 13:30:06 testclient automount[17792]: mount(nfs): nfs: mount
failure ipanfs.linux.mydomain.at:/homeshare on /home
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 55
Apr 14 13:30:06 testclient automount[17792]: failed to mount /home
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 56, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 56
Apr 14 13:30:06 testclient automount[17792]: handle_packet: type = 5
Apr 14 13:30:06 testclient automount[17792]:
handle_packet_missing_direct: token 57, name /home, request pid 17808
Apr 14 13:30:06 testclient automount[17792]: dev_ioctl_send_fail: token
= 57
I would like to start with sec=sys - why doest the user get a permission
denied even if its home directory appears to have the right permissions?
Where do I have to look into?
Regards,
Ronald Wimmer
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] add trust between FreeIPA and Samba AD DC
On to, 13 huhti 2017, Alexander Bokovoy wrote: On Thu, 13 Apr 2017, Tiemen Ruiten wrote: Excerpt from the httpd error_log on the FreeIPA replica: [Thu Apr 13 11:17:44.072996 2017] [:error] [pid 28346] ipa: INFO: [jsonserver_kerb] ad...@i.rdmedia.com: ping(): SUCCESS [Thu Apr 13 11:17:50.708019 2017] [:error] [pid 28347] ipa: ERROR: non-public: RuntimeError: (-1073741811, 'Unexpected information received') Please add 'log level = 10' to /usr/share/ipa/smb.conf.empty and re-try 'ipa trust-add', then send me resulting error_log privately. To get back to the public mailing list, Tiemen sent me logs and I confirm that this is the same as https://bugzilla.redhat.com/show_bug.cgi?id=1421869 We currently have no solution to this problem (AD is subdomain of IPA domain). -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] replica creation problems
On 04/13/2017 07:50 PM, Josh wrote: Scenario: RHEL7 IPA with DNS and without CA. Initial installation was done using --http-cert-file, --dirsrv-cert-file with certificates from an issuer A. For a number of reasons replica must be created with certificates from an issuer B. A bundle consisting of key, server certificate and a full certificate chain provided by the issuer B is prepared as replica.crt IPA Replica file created as ipa-replica-prepare --dirsrv-cert-file=replica.crt --http-cert-file=replica.crt --dirsrv-pin=key_pass --http-pin=key_pass --ip-address=n.n.n.n --password=manager_pass replica_host_name no errors/warnings during above process. Resulting file transferred to a new clean system and launched as # ipa-replica-install --setup-dns --auto-forwarders --mkhomedir /var/lib/ipa/replica-replica_host_name.gpg Directory Manager (existing master) password: Checking DNS forwarders, please wait ... Run connection check to master admin@REALM password: Connection check OK Adding [n.n.n.n replica_host_name] to your /etc/hosts file Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/42]: creating directory server user [2/42]: creating directory server instance [3/42]: updating configuration in dse.ldif [4/42]: restarting directory server [5/42]: adding default schema [6/42]: enabling memberof plugin [7/42]: enabling winsync plugin [8/42]: configuring replication version plugin [9/42]: enabling IPA enrollment plugin [10/42]: enabling ldapi [11/42]: configuring uniqueness plugin [12/42]: configuring uuid plugin [13/42]: configuring modrdn plugin [14/42]: configuring DNS plugin [15/42]: enabling entryUSN plugin [16/42]: configuring lockout plugin [17/42]: configuring topology plugin [18/42]: creating indices [19/42]: enabling referential integrity plugin [20/42]: configuring ssl for ds instance [21/42]: configuring certmap.conf [22/42]: configure autobind for root [23/42]: configure new location for managed entries [24/42]: configure dirsrv ccache [25/42]: enabling SASL mapping fallback [26/42]: restarting directory server [27/42]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 15 seconds elapsed [master_host_name] reports: Update failed! Status: [-11 - LDAP error: Connect error] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. ipa.ipapython.install.cli.install_tool(Replica): ERRORFailed to start replication ipa.ipapython.install.cli.install_tool(Replica): ERRORThe ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information Log file does not list any obvious errors other then full call stack which tell me nothing, I can post it here if helps. Both machines run no firewall and are on the same subnet. Additional problems noticed during cleanup attempt: # /usr/sbin/ipa-server-install --uninstall This is a NON REVERSIBLE operation and will delete all data and configuration! Are you sure you want to continue with the uninstall procedure? [no]: yes Replication agreements with the following IPA masters found: master_host_name. Removing any replication agreements before uninstalling the server is strongly recommended. You can remove replication agreements by running the following command on any other IPA master: $ ipa-replica-manage del replica_host_name Are you sure you want to continue with the uninstall procedure? [no]: Aborting uninstall operation. Going to master and running $ ipa-replica-manage del replica_host_name fails with Connection to 'replica_host_name' failed: cannot connect to 'ldaps://replica_host_name:636': TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. Unable to delete replica 'replica_host_name' I attempted to provide --cacert=full_path_to_issuer_B_bundle option but nothing changed. As a matter of fact providing invalid file name to --cacert does not raise any error. Strace output confirm that file listed in --cacert is not Only appending the bundle to /etc/ipa/ca.crt resolved TLS errors. Please advise how I can find root cause of LDAP error: Connect error. I have a suspicion that master LDAP can't connect to replica LDAP for above mentioned TLS reason. Josh. Hi Josh, I did not try this type of setup myself, but I think the issue comes from missing root certificates. I would try to run $ ipa-cacert-manage --install $ ipa-certupdate on the master. This command will install issuer B certificate as a trusted CA on the master, thus allowing communications with services (eg LDAP on replica) using certificates delivered by issuer B. You may find more information in
