Re: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3
On Fri, 17 Oct 2014, Vaclav Adamec wrote: Hi, is there any valid documentation/setup to get sudo working? http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/example-configuring-sudo.html is not usable, modification of another files are needed to get at least attempts to ldap (for example on CentOS /etc/sudo-ldap.conf). Other documentation or googled setup seems to sometimes mixture of not very compatible settings. So far all attempts fails, if you want to see actual setup and state see public gist - https://gist.github.com/VAdamec/58880b3bb476a0b826e6#file-freeipa-403-debug-log Any help would be appreciated, also if there is any public training/certification please get me know (I found only RedHat which is based on older versions) FreeIPA 4.0.3 has sudo configuration integrated into ipa-client-install by default. If you don't want to use that, you can run ipa-client-install --no-sudo. Now, I'm confused by your logs. They are a mixture of unrelated things: - you have nslcd and sssd configured at the same time. Why? - you don't need to configure /etc/sudo-ldap.conf if you are using sssd. As Dmitri said, configuration described in http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf and also covered in SSSD manual pages, sssd-sudo(5). In particular, it says since sssd 1.10.0: --- When the SSSD is configured to use IPA as the ID provider, the sudo provider is automatically enabled. The sudo search base is configured to use the compat tree (ou=sudoers,$DC). --- Prior to that it included detailed configuration how to set up sudo for SSSD with IPA provider. -- / 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] Valid documentation for sudo setup for version 4.0.3
On Fri, 17 Oct 2014, Vaclav Adamec wrote: Mixture of bot method is result of testing, just registration via ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6, but right now: Installing 4.x (client or server) is not supported on CentOS 6.x. You can use whatever IPA version is available there (3.0).It will not automatically configure sudo for you, there you have to follow what sssd-sudo(5) tells you to do. My primary point was that we have this documentation available on every machine where SSSD is in use, no need to search over internet. P.S. Please reply to the list, not personally. -- / 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] Valid documentation for sudo setup for version 4.0.3
Thanks for your time. Man pages were the first, but it's not working just base on that. Find out that libsss_sudo is desperately needed and it's not required by ipa-client rpm. So now I only need to check sudo policy in IPA, as there is obviously some issue, but connection is working. yum install ipa-client libsss_sudo ipa-client-install ... modify: /etc/sssd/sssd.conf (ldap setup based on man) /etc/nsswitch.conf (sss provider for sudoers based on man) and result: [vaclav.adamec@ipa-client~]$ groups vaclav.adamec admins [vaclav.adamec@ipa-client ~]$ sudo -l vaclav.adamec is not allowed to run sudo on ipa-client. This incident will be reported. (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [vaclav.adamec] from [ALL] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [vaclav.adamec@test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [vaclav.adamec@test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [vaclav.adamec] from [test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vaclav.adamec)(sudoUser=#108581)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*))((dataExpireTimestamp=1413529436)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=vaclav.adamec)(sudoUser=#108581)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [vaclav.adamec@test] but ldap search: ldapsearch -x -h localhost -p 389 -b ou=sudoers,dc=test # sudoers, test dn: ou=sudoers,dc=test objectClass: extensibleObject ou: sudoers # Admins_can_do_anything, sudoers, test http://cz.avg.com dn: cn=Admins_can_run_whomai_as_root,ou=sudoers,dc=test sudoUser: %admins sudoHost: +all objectClass: sudoRole objectClass: top sudoRunAsUser: root sudoCommand: /usr/bin/whoami cn: Admins_can_run_whomai_as_root # search result search: 2 result: 0 Success On Fri, Oct 17, 2014 at 8:39 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Fri, 17 Oct 2014, Vaclav Adamec wrote: Mixture of bot method is result of testing, just registration via ipa-client (maybe CentOS 6 has only ipa-client-3.0.0-37 ?) definitely not setup anything about sudo. I'll try to build 4.0.3 client for CentOS 6, but right now: Installing 4.x (client or server) is not supported on CentOS 6.x. You can use whatever IPA version is available there (3.0).It will not automatically configure sudo for you, there you have to follow what sssd-sudo(5) tells you to do. My primary point was that we have this documentation available on every machine where SSSD is in use, no need to search over internet. P.S. Please reply to the list, not personally. -- / 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
Replying to myself is great... Anyway, maybe this info will be useful for people like me, trying to integrate FreeBSD with FreeIPA. Solved some problems: 1. SSH-ing as existing IPA user rsiwal to my FreeBSD client fails. The same user can SSH or locally login to my Linux client. That happened because the shell specified for user rsiwal was /bin/bash. After changing it to /bin/sh that problem disappeared. 2. At the same time I cannot locally login to my FreeBSD host as either IPA user or local user. I posted the cause and solution at FreeBSD forums: https://forums.freebsd.org/threads/freebsd-freeipa-via-sssd.46526/ 3. If I create a new user in IPA, he can`t initially SSH into FreeBSD client. BSD says: password expired, but doesn`t take new password. The same new user can SSH into my Linux client. Linux says: password expired and allows to set a new password with a message: All authentication tokens updated successfully. After I set a new password for my newly created user via Linux, I can SSH into my BSD client as that user. Using this hack I can create new users in IPA, SSH into Linux to change their passwords and then use those new users to SSH into FreeBSD. Didn`t find a solution yet. But I think this is caused by lack of proper configuration of Kerberos on my FreeBSD client. On my Linux client I found such a configuration in /etc/krb5.conf file. However, there's no such file on my FreeBSD client, as the post on FreeBSD forums didn't say anything about such a file. I'll do some more checks and share the results here. 16-Oct-14 18:23, Orkhan Gasimov пишет: Here`s what I have at the end of the day after various checks. SSH-ing as existing IPA user rsiwal to my FreeBSD client fails. The same user can SSH or locally login to my Linux client. If I create a new user in IPA, he can`t initially SSH into FreeBSD client. BSD says: password expired, but doesn`t take new password. The same new user can SSH into my Linux client. Linux says: password expired and allows to set a new password with a message: All authentication tokens updated successfully. After I set a new password for my newly created user via Linux, I can SSH into my BSD client as that user. Using this hack I can create new users in IPA, SSH into Linux to change their passwords and then use those new users to SSH into FreeBSD. At the same time I cannot locally login to my FreeBSD host as either IPA user or local user. I think there`s something wrong with Kerberos setup on my FreeBSD client. I suspect that because both /etc/pam.d/system and /etc/pam.d/sshd files on the BSD client have a string: password sufficient /usr/local/lib/pam_sss.so use_authtok but BSD doesn`t let update authentication tokens when trying to change expired password for a new user. There was minimal info about Kerberos setup on FreeBSD client in the post at FreeBSD forums. Just this: create a keytab on the IPA server and copy it to /etc/krb5.keytab on the FreeBSD client. Someone here wrote that he can contact the author of that post. If so, please tell the author to spend a couple of hours to: 1) check everything he advised on a blank setup with VMs; 2) provide more details about correct sequence of actions. Any help will be highly appreciated! 16-Oct-14 15:13, Orkhan Gasimov пишет: Please excuse me for that silly typo in the letter. The typo doesn`t exist either in /etc/pam.d/system or /etc/pam.d/sshd - in those files I typed ignore_unknown_user. I'll try ignore_authinfo_unavail to see if it prevents me from being locked out of the machine. Here are the log files: sssd_eurosel.az.log: https://cloud.mail.ru/public/1e803a00989e%2Fsssd_eurosel.az.log sssd_nss.log: https://cloud.mail.ru/public/ae41ae3b44b6%2Fsssd_nss.log sssd_pam.log: https://cloud.mail.ru/public/85d311ec1d4e%2Fsssd_pam.log krb5_child.log: https://cloud.mail.ru/public/c0e6712b7f1b%2Fkrb5_child.log ldap_child.log: https://cloud.mail.ru/public/d9b0b1eb0da6%2Fldap_child.log sssd_log: https://cloud.mail.ru/public/d4032b8e6645%2Fsssd.log 16-Oct-14 14:57, Lukas Slebodnik пишет: On (16/10/14 13:04), Orkhan Gasimov wrote: OK, back to FreeIPA - FreeBSD setup. I changed my setup: instead of 2 VMs now I have 4 VMs: 1: DNS server - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=0SmiwFoHVeIindex=4list=PLdKXnZQzEG-KmtKq-LelPn5RTKfJig0Wc 2 and 3: IPA server IPA linux client - set up as shown by Rajnesh Kumar Siwal in http://www.youtube.com/watch?v=_zlcxjkbayk 4: IPA BSD client - set up as described in the post at FreeBSD forums. Results: 1) my IPA linux client interacts fine with the IPA server; 2) my IPA BSD client also interacts with the IPA server: it sees IPA users when issuing getent passwd or getent shadow. (Previously when I used just 2 VMs and no DNS server, that didn`t happen.) Problems after I start sssd on the FreeBSD client: 1) I can`t ssh into my IPA BSD client either as an IPA user (rsiwal) or local
Re: [Freeipa-users] Valid documentation for sudo setup for version 4.0.3
On Fri, 17 Oct 2014, Vaclav Adamec wrote: Thanks for your time. Man pages were the first, but it's not working just base on that. Find out that libsss_sudo is desperately needed and it's not required by ipa-client rpm. So now I only need to check sudo policy in IPA, as there is obviously some issue, but connection is working. This was work in progress in RHEL6.x, we didn't setup sudo from ipa-client-instal, we weren't forcing it rpm-wise. Now, with SSSD 1.10 and above SSSD packages libsss_sudo in the main SSSD package, sssd-common, so there is no need to add more dependencies. yum install ipa-client libsss_sudo ipa-client-install ... modify: /etc/sssd/sssd.conf (ldap setup based on man) /etc/nsswitch.conf (sss provider for sudoers based on man) and result: [vaclav.adamec@ipa-client~]$ groups vaclav.adamec admins [vaclav.adamec@ipa-client ~]$ sudo -l vaclav.adamec is not allowed to run sudo on ipa-client. This incident will be reported. (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_cmd_parse_query_done] (0x0200): Requesting rules for [vaclav.adamec] from [ALL] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0200): Requesting info about [vaclav.adamec@test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning info for user [vaclav.adamec@test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x0400): Retrieving rules for [vaclav.adamec] from [test] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=vaclav.adamec)(sudoUser=#108581)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*))((dataExpireTimestamp=1413529436)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to get sudo rules from cache (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [((objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=vaclav.adamec)(sudoUser=#108581)(sudoUser=%admins)(sudoUser=%vaclav.adamec)(sudoUser=+*)))] (Fri Oct 17 09:03:56 2014) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 1 rules for [vaclav.adamec@test] but ldap search: ldapsearch -x -h localhost -p 389 -b ou=sudoers,dc=test # sudoers, test dn: ou=sudoers,dc=test objectClass: extensibleObject ou: sudoers # Admins_can_do_anything, sudoers, test http://cz.avg.com dn: cn=Admins_can_run_whomai_as_root,ou=sudoers,dc=test sudoUser: %admins sudoHost: +all objectClass: sudoRole objectClass: top sudoRunAsUser: root sudoCommand: /usr/bin/whoami cn: Admins_can_run_whomai_as_root # search result search: 2 result: 0 Success Both the SSSD logs and your ldapsearch say that they found the rule. However, you didn't show logs for applying the rule. Sudo integration is a bit complex. Since sudo 1.8.8, there is a code in sudo which implements sudoers support through SSSD and there is a code in SSSD which complements the sudo's part by supplying actual data to the sudo part. Sudo code dynamically loads SSSD module and actual debugging info about parsing rules is available from the sudo. To enable the debugging, make a /etc/sudo.conf file with a line: Debug sudo /var/log/sudo_debug all@info If you would run a sudo command that wouldn't match any of the rules, you'd see following output in /var/log/sudo_debug: Oct 17 11:16:36 sudo[3794] username=admin Oct 17 11:16:36 sudo[3794] domainname=NULL Oct 17 11:16:36 sudo[3794] Received 1 rule(s) Oct 17 11:16:36 sudo[3794] netgroup c21.ipacloud.test has no leading '+' Oct 17 11:16:36 sudo[3794] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH! Oct 17 11:16:36 sudo[3794] netgroup admins has no leading '+' Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=6 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] sudo_emalloc: cnt=1 Oct 17 11:16:36 sudo[3794] searching SSSD/LDAP for sudoers entries Oct 17 11:16:36 sudo[3794] sssd/ldap sudoRunAsUser 'root' ... MATCH! Oct 17 11:16:36 sudo[3794] sssd/ldap sudoCommand '/usr/bin/whoami' ... not Oct 17 11:16:36 sudo[3794] Done with LDAP searches The last 'not' is an indicator the command is refused thanks to the rule. For correct match you'd get something like this: Oct 17 11:19:36 sudo[3835] username=admin Oct 17 11:19:36 sudo[3835] domainname=NULL Oct 17 11:19:36 sudo[3835] Received 1 rule(s) Oct 17 11:19:36 sudo[3835] netgroup c21.ipacloud.test has no leading '+' Oct 17 11:19:36 sudo[3835] sssd/ldap sudoHost 'cc21.ipacloud.test' ... MATCH! Oct 17 11:19:36 sudo[3835] netgroup admins has no leading '+' Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=6 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17 11:19:36 sudo[3835] sudo_emalloc: cnt=1 Oct 17
Re: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server
On (17/10/14 12:01), Alexander Bokovoy wrote: Didn`t find a solution yet. But I think this is caused by lack of proper configuration of Kerberos on my FreeBSD client. On my Linux client I found such a configuration in /etc/krb5.conf file. However, there's no such file on my FreeBSD client, as the post on FreeBSD forums didn't say anything about such a file. I'll do some more checks and share the results here. Well, follow your Kerberos library defaults. By default FreeBSD is built with Heimdal so if your system uses Heimdal and SSSD is build against It is true that default Kerberos library on FreeBSD is Heimdal. It is stored in default paths (/usr/bin, /usr/lib). SSSD does not work with Heimdal, therefore it is linked with MIT krb5 = 1.10 on FreeBSD, which is stored in (/usr/local/bin, /usr/local/lib) LS -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
This idea is great, it would be invaluable for many people trying to integrate FreeBSD with FreeIPA. Currently there's only one post about this at FreeBSD forums, but it's not detailed and tells nothing about many cavets of the process. You would have helped a lot of people to avoid frustration. 17-Oct-14 14:01, Alexander Bokovoy пишет: See ipa-advise tool on IPA server. Currently it only provides you with config-freebsd-nss-pam-ldapd advise to configure FreeBSD with nss-pam-ldapd, but we can extend that to have SSSD covered too. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
Unfortunately, putting that line in /etc/pam.d/system prevents me from being able to locally login to the BSD client. At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login doesn't give unexpected behaviours. Bug, bug, bug... 17-Oct-14 14:15, Lukas Slebodnik пишет: I would reccomend to have next line in /etc/pam.d/system and /etc/pam.d/sshd. Without this line, access control will not work. (HBAC) account required /usr/local/lib/pam_sss.so ignore_unknown_user ignore_authinfo_unavail -- 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] Valid documentation for sudo setup for version 4.0.3
On 10/17/2014 10:21 AM, Alexander Bokovoy wrote: On Fri, 17 Oct 2014, Vaclav Adamec wrote: Thanks for your time. Man pages were the first, but it's not working just base on that. Find out that libsss_sudo is desperately needed and it's not required by ipa-client rpm. So now I only need to check sudo policy in IPA, as there is obviously some issue, but connection is working. This was work in progress in RHEL6.x, we didn't setup sudo from ipa-client-instal, we weren't forcing it rpm-wise. Now, with SSSD 1.10 and above SSSD packages libsss_sudo in the main SSSD package, sssd-common, so there is no need to add more dependencies. Please note that ipa-client-install in RHEL-6.6 now also configures sudo automatically! See https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/6.6_Release_Notes/authentication.html for the release note. Martin -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: That format is not simple for me, as I'm not a programmer. But after I check, double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and assure that it works without unexpected behaviors, I'll probably write a HOW-TO on this process and post it at FreeBSD forums. Thanks! Would you consider also adding the HOWTO to http://www.freeipa.org/page/HowTos so that other people can follow your steps? I'll then share the link to my post here, so that: 1) FreeIPA community could also check the post for any errors; 2) someone more prepared could translate the whole process into the format appropriate for the ipa-advise tool. 17-Oct-14 15:37, Alexander Bokovoy пишет: FreeIPA is an open source project where anyone can contribute in their areas of interest. You are welcome to contribute recipes for FreeBSD. The code is around https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py As you can see, most recipes are structured in easy way and adding new is as simple as adding new class definition there. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
Of course! But for now I'm in process of checking my integration and there are some things I don't like. First and foremost, any change on the IPA server is not automatically reflected on the BSD client. Only after SSSD is manually restarted on the client, something like it's cache is cleared happens and new rules apply. For now I'm not even checking something complex like sudo rule groups with host groups, it's just a simple sudo rule for a single user. I hope for collaboration with other interested people to find a stable solution for FreeIPA - FreeBSD interaction via SSSD, so that as a result of all this effort a well-detailed tutorial could be written and shared with all *nix users. 17-Oct-14 16:17, Martin Kosek пишет: On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: That format is not simple for me, as I'm not a programmer. But after I check, double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and assure that it works without unexpected behaviors, I'll probably write a HOW-TO on this process and post it at FreeBSD forums. Thanks! Would you consider also adding the HOWTO to http://www.freeipa.org/page/HowTos so that other people can follow your steps? I'll then share the link to my post here, so that: 1) FreeIPA community could also check the post for any errors; 2) someone more prepared could translate the whole process into the format appropriate for the ipa-advise tool. 17-Oct-14 15:37, Alexander Bokovoy пишет: FreeIPA is an open source project where anyone can contribute in their areas of interest. You are welcome to contribute recipes for FreeBSD. The code is around https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py As you can see, most recipes are structured in easy way and adding new is as simple as adding new class definition there. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On (17/10/14 15:44), Orkhan Gasimov wrote: Unfortunately, putting that line in /etc/pam.d/system prevents me from being able to locally login to the BSD client. At the same time, the same line in /etc/pam.d/sshd or /etc/pam.d/login doesn't give unexpected behaviours. Bug, bug, bug... It works for me with FreeBSD 9.3. It is possible that your pam stack is misconfigured. Which version of FreBSD do you use? Could you send me all files from /etc/pam.d/? LS -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On 10/17/2014 01:28 PM, Orkhan Gasimov wrote: Of course! But for now I'm in process of checking my integration and there are some things I don't like. First and foremost, any change on the IPA server is not automatically reflected on the BSD client. Only after SSSD is manually restarted on the client, something like it's cache is cleared happens and new rules apply. For now I'm not even checking something complex like sudo rule groups with host groups, it's just a simple sudo rule for a single user. I hope for collaboration with other interested people to find a stable solution for FreeIPA - FreeBSD interaction via SSSD, so that as a result of all this effort a well-detailed tutorial could be written and shared with all *nix users. +1. Or, even better approach would be if ipa-client-install script gets ported some nice day to FreeBSD so that sssdassorted services do not need to be configured automatically and can use autodiscover features of ipa-client-install. But this is even farther future :-) 17-Oct-14 16:17, Martin Kosek пишет: On 10/17/2014 01:01 PM, Orkhan Gasimov wrote: That format is not simple for me, as I'm not a programmer. But after I check, double-check and triple-check my FreeBSD - FreeIPA integration via SSSD and assure that it works without unexpected behaviors, I'll probably write a HOW-TO on this process and post it at FreeBSD forums. Thanks! Would you consider also adding the HOWTO to http://www.freeipa.org/page/HowTos so that other people can follow your steps? I'll then share the link to my post here, so that: 1) FreeIPA community could also check the post for any errors; 2) someone more prepared could translate the whole process into the format appropriate for the ipa-advise tool. 17-Oct-14 15:37, Alexander Bokovoy пишет: FreeIPA is an open source project where anyone can contribute in their areas of interest. You are welcome to contribute recipes for FreeBSD. The code is around https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/advise/plugins/legacy_clients.py As you can see, most recipes are structured in easy way and adding new is as simple as adding new class definition there. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On (17/10/14 16:28), Orkhan Gasimov wrote: Of course! But for now I'm in process of checking my integration and there are some things I don't like. First and foremost, any change on the IPA server is not automatically reflected on the BSD client. sssd uses few levels of caches. If you want to have up-to-date data you need to invalidate sssd cache (sss_cache -UG). Details are in man sss_cache. It is not related to FreeBSD. The same behaviour is on LInux. If user authenticates to machine with sssd then fresh data is downloaded from server. That's the only exception. Only after SSSD is manually restarted on the client, something like it's cache is cleared happens and new rules apply. For now I'm not even checking something complex like sudo rule groups with host groups, it's just a simple sudo rule for a single user. sudo is much more tricky about up-to-date data. sssd uses peridic tasks for refreshing rules. It is not possible to invalidate sudo rules with tool sss_cache. Detail description of sudo rules caching mechanism is in manual page man sssd-sudo - THE SUDO RULE CACHING MECHANISM LS -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
I found another solution (currently checked it only for adding/deleting a sudo rule for a user, and also enabling/disabling a user) - add to the [domain] section of the sssd.conf file: entry_cache_timeout = 5. 17-Oct-14 16:39, Lukas Slebodnik пишет: sssd uses few levels of caches. If you want to have up-to-date data you need to invalidate sssd cache (sss_cache -UG). -- 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] Migration fails with custom objectClasses
Hi, maybe there is a case problem, if I try the following command, note some capital letters: # ipa config-mod --userobjectclasses=ipaObject --userobjectclasses=ine*tO*rgperson --userobjectclasses=person --userobjectclasses=posixaccount --userobjectclasses=inetuser --userobjectclasses=organizational*P*erson --userobjectclasses=krbticketpolicyaux --userobjectclasses=krbprincipalaux ipa: ERROR: Type or value exists: it fails, doing the same with all lowercase succeeds: # ipa config-mod --userobjectclasses=ipaobject --userobjectclasses=inetorgperson --userobjectclasses=person --userobjectclasses=posixaccount --userobjectclasses=inetuser --userobjectclasses=organizationalperson --userobjectclasses=krbticketpolicyaux --userobjectclasses=krbprincipalaux . Default user objectclasses: ipaobject, person, inetorgperson, organizationalperson, krbticketpolicyaux, krbprincipalaux, inetuser, posixaccount You posted your default oc earlier to be: Default user objectclasses: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, radiusProfile, customPersonAttributes, sambaSamAccount and in the migration code we have code like: entry_attrs['objectclass'] = list( set( config.get( ldap_obj.object_class_config, ldap_obj.object_class ) + [o.lower() for o in entry_attrs['objectclass']] ) ) so i assume it will try to add an entry with objectclass: customPersonAttributes objectclass: custompersonattributes I don't know how to get ipa to log this, but you could do: tcpdump 'tcp port 389' -i any -w migrat.pcap and then run migrate-ds to verify On 10/16/2014 09:47 PM, Clint Savage wrote: On Thu, Oct 16, 2014 at 12:59 PM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 10/16/2014 11:42 AM, Clint Savage wrote: The access log had that information. And this error log: https://www.dropbox.com/s/ak6za0dkr0cn7ay/errors.20141010-132318 There unfortunately doesn't seem to be a debug log level that will tell the server to dump the add request with all arguments. The best bet would be to get the ipa migrate tool to dump it's commands to LDIF format, then we can look at it and figure out what it is doing wrong. I don't know if that's possible. Does anyone know how to accomplish what Rich suggests above? Thanks, Clint -- 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] ipa-client-install (Invalid Request) - no Host-Certificate
christof.schu...@ww.uni-erlangen.de wrote: The FreeIPA is 3.0.0 server is running on CentOS 6.5. The CA subsystem certificates have all been renewed and will expire not until 2016. In the I think the problems come from modifications a colleague did to /etc/httpd/ipa-pki-proxy.conf , /etc/httpd/nss.conf and /var/lib/pki-ca/conf/server.xml (without dokumentation, but they have different timestamps) when he wanted to enforce/enable higher level encrytion. I was able to reproduce some of his changes like StrictCypher and sslOptions he did, but I am not sure with the configuraion of the ports of the connectors in /var/lib/pki-ca/conf/server.xml Connector name=Agent port=9443... !-- Port Separation: Admin Secure Port Connector -- Connector name=Admin port=9445 ... !-- Port Separation: EE Secure Port Connector -- Connector name=EE port=9444 ... !-- Port Separation: EE Secure Client Auth Port Connector -- Connector name=EEClientAuth port=9446 ... !-- Define an AJP 1.3 Connector on port 9447 -- Connector port=9447 protocol=AJP/1.3 redirectPort=9444 / and the /etc/httpd/conf.d/ipa-pki-proxy.conf # VERSION 2 - DO NOT REMOVE THIS LINE ProxyRequests Off # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none #ProxyPassMatch ajp://localhost:9443 #ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 /LocationMatch # matches for admin port and installer LocationMatch ^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none #ProxyPassMatch ajp://localhost:9443 #ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 /LocationMatch # matches for agent port and eeca port LocationMatch ^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient require #ProxyPassMatch ajp://localhost:9443 #ProxyPassReverse ajp://localhost:9443 ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 /LocationMatch # Only enable this on servers that are not generating a CRL #RewriteRule ^/ipa/crl/MasterCRL.bin https://ww8-idm.ww.uni-erlangen.de/ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL [L,R=301,NC] Is there somewhere a example configuration? When I deployed the system it was a rather default installation. I've attached the config files from one of my working 3.0.0 masters. rob Christof Schulze wrote: Hello all, i am running a FreeIPA server on CentOS for 2 years now with mostly Ubuntu 12.04 and some Fedora 20 clients. Since one week (or more) it is not possible any more to install new clients (whether ubuntu nor fedora). The Host gets created on the IPA-server but it can not create/exchange a Host-Certificate. The only thing happened (except regular updates) was a complete certificate renewal with no obvious problems some weeks ago. Web-interface and certmonger show the same error. ipa-getcert list on the new Hosts: status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Invalid Request)). stuck: yes Given the timeline I'd guess that your CA subsystem certificates have expired. On the IPA master run: getcert list (not ipa-getcert) This will show the current status of things. What version of IPA is this? rob # VERSION 2 - DO NOT REMOVE THIS LINE ProxyRequests Off # matches for ee port LocationMatch ^/ca/ee/ca/checkRequest|^/ca/ee/ca/getCertChain|^/ca/ee/ca/getTokenInfo|^/ca/ee/ca/tokenAuthenticate|^/ca/ocsp|^/ca/ee/ca/updateNumberRange|^/ca/ee/ca/getCRL NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:9447 ProxyPassReverse ajp://localhost:9447 /LocationMatch # matches for admin port and installer LocationMatch ^/ca/admin/ca/getCertChain|^/ca/admin/ca/getConfigEntries|^/ca/admin/ca/getCookie|^/ca/admin/ca/getStatus|^/ca/admin/ca/securityDomainLogin|^/ca/admin/ca/getDomainXML|^/ca/rest/installer/installToken NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate NSSVerifyClient none ProxyPassMatch ajp://localhost:9447
