From rcritten at redhat.com Mon Oct 1 14:23:23 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 01 Oct 2012 10:23:23 -0400 Subject: [Freeipa-users] Certificates for public facing web sites In-Reply-To: References: Message-ID: <5069A75B.6060208@redhat.com> Simon Williams wrote: > Hi > > Possibly a bit of a strange requirement, I don't really know! I have a > small business and am using IPA to manage our network. I have migrated > from an LDAP setup with a variety of different certificates lying around > for different applications and find IPA much easier to administer, > despite the fact that it probably overkill for a couple of users using > half a dozen hosts. > > I have a few named virtual hosts that provide access to web based > systems from outside the local network, but I do not have sufficient > control over the external domain's DNS to add a subdomain with it's own > DNS. I can add A records and CNAME records to point to the virtual > hosts, but I cannot add NS records to delegate name resolution to my own > DNS. The ISP I use does not allow dynamic DNS updates. I would like to > use FreeIPA to manage the SSL certificates for these virtual hosts using > mod_nss and have already implemented this successfully for virtual hosts > on the local domain, but since I do not control the public domain, I > can't see how to achieve this. > > Please forgive me if I am missing something obvious, but I've only been > using FreeIPA for two weeks and it is a testament to it's ease of use > that I have managed to get as far as I have with it in that time unaided! So the problem is your domain is example.com and is managed by IPA and you want to create certificates for someothercorp.com? You should be able to use the --force flag to create a host and create services/issue certificates from that point. rob From rmeggins at redhat.com Mon Oct 1 15:31:03 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 01 Oct 2012 09:31:03 -0600 Subject: [Freeipa-users] winsync agreement transferred users not going into ipausers and existing users dropped from all their groups In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546D5119@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546D485A@STAWINCOX10MBX1.staff.vuw.ac.nz>, <506479E3.1030104@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546D5077@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5064BF0A.3010904@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546D5119@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5069B737.6050602@redhat.com> On 09/27/2012 05:50 PM, Steven Jones wrote: > 8><-------- > >> This and not bringing over all users because the user can have a sub-folder for mobile phone sync so gets wiped by the previous bug we discussed are total show stoppers for our IPA and RHEL desktop deployment, > This is a new one, perhaps I missed it. If an AD user has a sub-folder, > that user is not synced to IPA, and due to #355 winsync should not > delete entry that appears to be out of scope it then is deleted from IPA? > > In this case, should winsync sync the sub-folder, or ignore it, and just > sync the user entry? > > I think I asked / suggested for this as a flag --exclude-subfolders or similar....It might fix it but AD's can be modded so much it might be a nightmare and you will need some serious testing per site. > > 8><--------- > > I will try and describe this as best I can.... > > so the user is (hope this is understandable) > > cn=user,ou=VUW_Staff,dc=staff,dc=vuw etc > > What looks to be happening is (my best guess) the user gets synced over as its -win-subtree= ou=VUW_Staff,dc=staff,dc=vuw etc but then there is a sort of simlink thing from cn=exchangesyncusers,cn=user,dc=staff,dc=vuw etc thats actually to a subdirectory under some of users... The ones with mobile smart phones, maybe you can swing an iphone5 each to test...;) > > Hence I think the known bug coming into play as the agreement is moving the user over and its next object is the cn=exchangesyncusers,cn=user,ou=VUW_Staff,dc=vuw etc so it promptly deletes the user it just added. > > This exchange-sync-user subfolder is invisible until you go to advanced view and turn the users into folders and scroll down and find the user (it took our exchange guru to show me) at that point this sync to exchange folder "appears" and its oops time. > > :/ > > I guess the problem is AD can be changed so much from a vanilla layout that finding these odd things and allowing for it in the winsync command is a bit of a nightmare, especially if you dont know there is an advanced AD view! > > I certainly suggest that unless whomever can deploy this doesnt do it live first off but in a test environment with a FULL copy of their AD. My management actually wanted me to do a simple test AD environment as a trial, that wouldnt have picked this up until too late when I did it on production. > > I think I asked for a --exclude-subfolders flag which would cover our disabled users as its a subfolder under the --win-subtree=OU=VUW_Staff....but it looks like this is a symlink at a peer level, so actually fixing the #355 bug would stop it being an issue I think. Not sure what you mean by "symlink" (referral? alias?) but if #355 allows user entries that are non-leaf entries to sync then that's good. As far as exclude-subfolders, that's https://fedorahosted.org/389/ticket/460 > > Im at home today so I cant supply much more info right now but I'll try on Monday if you need more... > > regards From qchang at sri.utoronto.ca Mon Oct 1 21:03:21 2012 From: qchang at sri.utoronto.ca (Qing Chang) Date: Mon, 01 Oct 2012 17:03:21 -0400 Subject: [Freeipa-users] Keep Samba password in sync with userpassword and kerberos password Message-ID: <506A0519.2050506@sri.utoronto.ca> In a thread on Freeipa-devel titled "freeIPA as a samba backend"there is a statement as below: ===== IPA will keep all of your passwords in sync - userPassword, sambaNTPassword, sambaLMPassword, and your kerberos passwords. 389 cannot do this - the functionality that does this is provided by an IPA password plugin. Openldap has a similar plugin, but I think it is "contrib" and not "officially supported". ====== Can someone please point me to where I can find this plugin and configured it to keep all passwords listed above in sync? I am unable to find detailed information on password plugin in IPA 2.2 doc. My intention is to provide my Windows users (accounts on IPA server) IPA web interface only for changing their password. I am using Samba 3.0.23d as a standalone server because this is a last version that does not check for SIDs strictly... Many thanks, Qing -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.williams at thehelpfulcat.com Mon Oct 1 22:31:10 2012 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Mon, 1 Oct 2012 23:31:10 +0100 Subject: [Freeipa-users] Fwd: Re: Certificates for public facing web sites In-Reply-To: <5069A75B.6060208@redhat.com> References: <5069A75B.6060208@redhat.com> Message-ID: Fantastic, I knew about the flag, but thought it only worked on hosts. It works on services too, which solves the problem. Thank you. ---------- Forwarded message ---------- From: "Rob Crittenden" Date: Oct 1, 2012 3:23 PM Subject: Re: [Freeipa-users] Certificates for public facing web sites To: "Simon Williams" Cc: Simon Williams wrote: > Hi > > Possibly a bit of a strange requirement, I don't really know! I have a > small business and am using IPA to manage our network. I have migrated > from an LDAP setup with a variety of different certificates lying around > for different applications and find IPA much easier to administer, > despite the fact that it probably overkill for a couple of users using > half a dozen hosts. > > I have a few named virtual hosts that provide access to web based > systems from outside the local network, but I do not have sufficient > control over the external domain's DNS to add a subdomain with it's own > DNS. I can add A records and CNAME records to point to the virtual > hosts, but I cannot add NS records to delegate name resolution to my own > DNS. The ISP I use does not allow dynamic DNS updates. I would like to > use FreeIPA to manage the SSL certificates for these virtual hosts using > mod_nss and have already implemented this successfully for virtual hosts > on the local domain, but since I do not control the public domain, I > can't see how to achieve this. > > Please forgive me if I am missing something obvious, but I've only been > using FreeIPA for two weeks and it is a testament to it's ease of use > that I have managed to get as far as I have with it in that time unaided! > So the problem is your domain is example.com and is managed by IPA and you want to create certificates for someothercorp.com? You should be able to use the --force flag to create a host and create services/issue certificates from that point. rob -------------- next part -------------- An HTML attachment was scrubbed... URL: From d.sastre.medina at gmail.com Tue Oct 2 08:39:29 2012 From: d.sastre.medina at gmail.com (David Sastre) Date: Tue, 2 Oct 2012 10:39:29 +0200 Subject: [Freeipa-users] Password failing for sudo-ldap authentication only from one host In-Reply-To: References: <50635240.1080100@redhat.com> <20120926210817.GB5907@pris.crapsteak.org> <20120927080126.GP25493@hendrix.brq.redhat.com> Message-ID: On Thu, Sep 27, 2012 at 10:53 AM, David Sastre wrote: > On Thu, Sep 27, 2012 at 10:01 AM, Jakub Hrozek wrote: > >> On Thu, Sep 27, 2012 at 08:18:21AM +0200, David Sastre wrote: >> > On Wed, Sep 26, 2012 at 11:08 PM, David Sastre Medina wrote: >> > > On Wed, Sep 26, 2012 at 03:06:40PM -0400, Rob Crittenden wrote: >> > > > David Sastre wrote: >> > > > > [big snip] >> > > > Does sssd work on this machine otherwise? getent passwd , you >> > > > can log into the console as the user, or perhaps kinit to the user? >> > > >> > It looks like sssd is operating correctly >> > I can also kinit w/o problems: >> >> kinit bypasses the SSSD and talks to the KDC directly. >> ...however, the ssh should go through the SSSD... >> >> Can you check the messages that appear in /var/log/secure during the >> sudo auth attempt? You should see pam_sss being contacted, what does it >> say? Is there any error? >> > > Jakub, > > Does your comment mean ssh/sshd is misbehaving or bad configured? > > There are, indeed, errors regarding pam_sss in /var/log/secure. > > This is a successful login+sudo+logout in a host: > > Sep 27 10:29:56 panoramix sshd[12913]: Authorized to dsastrem, krb5 > principal dsastrem at SOME.DOMAIN.COM (krb5_kuserok) > Sep 27 10:29:56 panoramix sshd[12913]: Accepted gssapi-with-mic for > dsastrem from 172.26.130.101 port 58678 ssh2 > Sep 27 10:29:56 panoramix sshd[12913]: pam_unix(sshd:session): session > opened for user dsastrem by (uid=0) > Sep 27 10:30:13 panoramix sudo: pam_unix(sudo:auth): authentication > failure; logname=dsastrem uid=0 euid=0 tty=/dev/pts/2 ruser=dsastrem > rhost= user=dsastrem > Sep 27 10:30:13 panoramix sudo: pam_sss(sudo:auth): authentication > success; logname=dsastrem uid=0 euid=0 tty=/dev/pts/2 ruser=dsastrem rhost= > user=dsastrem > Sep 27 10:30:13 panoramix sudo: dsastrem : TTY=pts/2 ; PWD=/home/dsastrem > ; USER=root ; COMMAND=/sbin/ip addr show > Sep 27 10:30:32 panoramix sshd[12942]: Received disconnect from > 172.26.130.101: 11: disconnected by user > Sep 27 10:30:32 panoramix sshd[12913]: pam_unix(sshd:session): session > closed for user dsastrem > > This one a failed attempt to do the same in another host: > > Sep 27 10:32:27 obelix sshd[5242]: Authorized to dsastrem, krb5 principal > dsastrem at SOME.DOMAIN.COM (krb5_kuserok) > Sep 27 10:32:27 obelix sshd[5242]: Accepted gssapi-with-mic for dsastrem > from 172.26.130.101 port 38276 ssh2 > Sep 27 10:32:27 obelix sshd[5242]: pam_unix(sshd:session): session opened > for user dsastrem by (uid=0) > Sep 27 10:32:50 obelix sudo: pam_unix(sudo:auth): authentication failure; > logname=dsastrem uid=0 euid=0 tty=/dev/pts/1 ruser=dsastrem rhost= > user=dsastrem > Sep 27 10:32:50 obelix sudo: pam_sss(sudo:auth): system info: [Permission > denied] > Sep 27 10:32:50 obelix sudo: pam_sss(sudo:auth): authentication failure; > logname=dsastrem uid=0 euid=0 tty=/dev/pts/1 ruser=dsastrem rhost= > user=dsastrem > Sep 27 10:32:50 obelix sudo: pam_sss(sudo:auth): received for user > dsastrem: 4 (System error) > Sep 27 10:33:13 obelix sudo: pam_unix(sudo:auth): conversation failed > Sep 27 10:33:13 obelix sudo: pam_unix(sudo:auth): auth could not identify > password for [dsastrem] > Sep 27 10:33:13 obelix sudo: pam_sss(sudo:auth): system info: [Cannot read > password] > Sep 27 10:33:13 obelix sudo: pam_sss(sudo:auth): authentication failure; > logname=dsastrem uid=0 euid=0 tty=/dev/pts/1 ruser=dsastrem rhost= > user=dsastrem > Sep 27 10:33:13 obelix sudo: pam_sss(sudo:auth): received for user > dsastrem: 4 (System error) > Sep 27 10:33:13 obelix sudo: dsastrem : 1 incorrect password attempt ; > TTY=pts/1 ; PWD=/home/dsastrem ; USER=root ; COMMAND=/sbin/ip addr show > Sep 27 10:33:21 obelix sshd[5281]: Received disconnect from 172.26.130.101: > 11: disconnected by user > Sep 27 10:33:21 obelix sshd[5242]: pam_unix(sshd:session): session closed > for user dsastrem > > I can see now where it is failing, but I can't understand why (yet), is > this PAM related? > For the record, and just in case it's useful for others, I solved this. These were the steps taken: - add debug_level = 10 to /etc/sssd/sssd.config - ssh to user and issue a sudo command - /var/log/sssd/krb5_child.log snippet: 1 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. 2 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [krb5_child_setup] (0x1000): Cannot read [SSSD_KRB5_LIFETIME] from environment. 3 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [krb5_child_setup] (0x4000): Not using FAST. 4 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [validate_tgt] (0x4000): Found keytab entry with the realm of the credential. 5 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [validate_tgt] (0x0200): TGT verified using key for [host/ obelix.some.domain.com at SOME.DOMAIN.COM]. 6 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [become_user] (0x4000): Trying to become user [1543400001][1543400001]. 7 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [create_ccache_file] (0x0020): mkstemp failed [13][Permission denied]. 8 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [get_and_save_tgt] (0x0020): 688: [13][Permission denied] 9 (Tue Oct 2 10:13:07 2012) [[sssd[krb5_child[28605]]]] [tgt_req_child] (0x0020): 919: [13][Permission denied] - verify no AVC denials exist in /var/log/audit/audit.log: 12 type=SYSCALL msg=audit(1349166186.421:6931172): arch=c000003e syscall=2 success=no exit=-13 a0=6235f0 a1=c2 a2=180 a3=7fff58d80dc0 items=1 ppid=28558 pid=30842 auid=500 uid=1543400001 gid=15 43400001 euid=1543400001 suid=1543400001 fsuid=1543400001 egid=1543400001 sgid=1543400001 fsgid=1543400001 tty=(none) ses=17963 comm="krb5_child" exe="/usr/libexec/sssd/krb5_child" subj=unco nfined_u:system_r:sssd_t:s0 key="access" 13 type=PATH msg=audit(1349166186.421:6931172): item=0 name="/tmp/.krb5cc_dummy_hiA8y9" inode=131104 dev=fd:15 mode=040757 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:tmp_t:s0 14 type=USER_AUTH msg=audit(1349166187.601:6931173): user pid=30807 uid=0 auid=1543400001 ses=17969 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="dsastrem" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/2 res=failed' - google a bit ( http://www.mail-archive.com/sssd-devel at lists.fedorahosted.org/msg10176.html) - restore expected /tmp permissions: # ll -dZ /tmp/ drwxr-xrwx. root root system_u:object_r:tmp_t:s0 /tmp/ # chmod g+w,o+t /tmp/ # ll -dZ /tmp/ drwxrwxrwt. root root system_u:object_r:tmp_t:s0 /tmp/ sudo works correctly again, thanks to the people in this list who spend time looking into this and pointed me in the right direction. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Oct 2 09:14:10 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 2 Oct 2012 11:14:10 +0200 Subject: [Freeipa-users] Password failing for sudo-ldap authentication only from one host In-Reply-To: References: <50635240.1080100@redhat.com> <20120926210817.GB5907@pris.crapsteak.org> <20120927080126.GP25493@hendrix.brq.redhat.com> Message-ID: <20121002091410.GD12623@hendrix.brq.redhat.com> On Tue, Oct 02, 2012 at 10:39:29AM +0200, David Sastre wrote: > sudo works correctly again, thanks to the people in this list who spend > time looking into this and pointed me in the right direction. I'm sorry I missed your previous reply, David. Glad sudo works for you now! From Steven.Jones at vuw.ac.nz Tue Oct 2 21:41:45 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 2 Oct 2012 21:41:45 +0000 Subject: [Freeipa-users] UID splitting policy and running out. Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E1CF4@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I just found that I had runout of UIDS when doing a winsync agreement. >From my understanding when you add a replica it takes 1/2 of the master's UIDs block...so a 2nd replica takes 1/2 of that again? In my case I rebuilt the replica's several times and the Master ended up with only 2500 UIDs left... When I did a winsync then it wasnt happy. I'd suggest that as part of the winsync setup a ldapsearch is done to make sure there are plenty left and allocate more if need be ....unless its a virgin setup....but a large site with say 2 replicas would leave 25000 UIDs on the master? not unusual for AD's to have 25000+ users I'd suggest. (we have about 21000). or did I do something wrong? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From simo at redhat.com Tue Oct 2 21:53:57 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 02 Oct 2012 17:53:57 -0400 Subject: [Freeipa-users] UID splitting policy and running out. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E1CF4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E1CF4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1349214837.22373.78.camel@willson.li.ssimo.org> On Tue, 2012-10-02 at 21:41 +0000, Steven Jones wrote: > Hi, > > I just found that I had runout of UIDS when doing a winsync agreement. > > >From my understanding when you add a replica it takes 1/2 of the master's UIDs block...so a 2nd replica takes 1/2 of that again? > > In my case I rebuilt the replica's several times and the Master ended up with only 2500 UIDs left... > > When I did a winsync then it wasnt happy. > > I'd suggest that as part of the winsync setup a ldapsearch is done to make sure there are plenty left and allocate more if need be ....unless its a virgin setup....but a large site with say 2 replicas would leave 25000 UIDs on the master? not unusual for AD's to have 25000+ users I'd suggest. (we have about 21000). > > or did I do something wrong? The DNA plugin should have reclaimed IDs when it was about to run off, can you please open a bug if that did not happen ? Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Oct 2 21:55:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 02 Oct 2012 17:55:46 -0400 Subject: [Freeipa-users] UID splitting policy and running out. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E1CF4@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E1CF4@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <506B62E2.2080605@redhat.com> On 10/02/2012 05:41 PM, Steven Jones wrote: > Hi, > > I just found that I had runout of UIDS when doing a winsync agreement. > > >From my understanding when you add a replica it takes 1/2 of the master's UIDs block...so a 2nd replica takes 1/2 of that again? > > In my case I rebuilt the replica's several times and the Master ended up with only 2500 UIDs left... > > When I did a winsync then it wasnt happy. > > I'd suggest that as part of the winsync setup a ldapsearch is done to make sure there are plenty left and allocate more if need be ....unless its a virgin setup....but a large site with say 2 replicas would leave 25000 UIDs on the master? not unusual for AD's to have 25000+ users I'd suggest. (we have about 21000). > > or did I do something wrong? The ranges are 200K wide as far as I remember so if you tried to sync and delete 10 times then you might have in fact depleted your range. But this is a not production environment situation. At this state it would be wise to start over with the clean staging environment. And you can also add more ranges if you hit this in production. See https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html#Managing-Unique_UID_and_GID_Attributes for more info. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Oct 5 12:32:56 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 08:32:56 -0400 Subject: [Freeipa-users] Keep Samba password in sync with userpassword and kerberos password In-Reply-To: <506A0519.2050506@sri.utoronto.ca> References: <506A0519.2050506@sri.utoronto.ca> Message-ID: <1349440376.22373.172.camel@willson.li.ssimo.org> On Mon, 2012-10-01 at 17:03 -0400, Qing Chang wrote: > In a thread on Freeipa-devel titled "freeIPA as a samba backend" there > is a statement as below: > ===== > IPA will keep all of your passwords in sync - userPassword, > sambaNTPassword, sambaLMPassword, and your kerberos passwords. > 389 cannot do this - the functionality that does this is provided by > an IPA password plugin. Openldap has a similar plugin, but I > think it is "contrib" and not "officially supported". > ====== > > Can someone please point me to where I can find this plugin and > configured it to keep all passwords listed above in sync? The plugin is automatically enabled in IPA, it is the only way to change passwords. > I am unable to find detailed information on password plugin in IPA 2.2 > doc. > > My intention is to provide my Windows users (accounts on IPA server) > IPA web interface only for changing their password. If you need to write a tool to change passwords keep in ming you can use ldappasswd and pass it old/new user password. > I am using Samba 3.0.23d as a standalone server because this is a last > version that does not check for SIDs strictly... > more recent versions of samba can also use the ldappasswd method. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbingram at gmail.com Fri Oct 5 16:16:51 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 5 Oct 2012 09:16:51 -0700 Subject: [Freeipa-users] saslauthd on freeipa machine Message-ID: As I typically have saslauthd use kerberos to authenticate users I really haven't had the occasion to try before. Since freeipa machines use SSSD to help manage users on the system, I thought that saslauthd should be able to authenticate users against PAM as well. Unless I have somehow misconfigured, this seems not to be the case as each time I get: saslauthd[7342] :do_auth : auth failure: [user=nancy] [service=smtp] [realm=] [mech=pam] [reason=PAM acct error] According to the logs on the freeipa machine, the auth is correct and the ticket is issued. Is there some additional client configuration required to make this work since SSSD now involved? Steve From dpal at redhat.com Fri Oct 5 17:03:34 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Oct 2012 13:03:34 -0400 Subject: [Freeipa-users] saslauthd on freeipa machine In-Reply-To: References: Message-ID: <506F12E6.8020706@redhat.com> On 10/05/2012 12:16 PM, Stephen Ingram wrote: > As I typically have saslauthd use kerberos to authenticate users I > really haven't had the occasion to try before. Since freeipa machines > use SSSD to help manage users on the system, I thought that saslauthd > should be able to authenticate users against PAM as well. Unless I > have somehow misconfigured, this seems not to be the case as each time > I get: > > saslauthd[7342] :do_auth : auth failure: [user=nancy] > [service=smtp] [realm=] [mech=pam] [reason=PAM acct error] > > According to the logs on the freeipa machine, the auth is correct and > the ticket is issued. Is there some additional client configuration > required to make this work since SSSD now involved? This seems relevant: http://www.howtoforge.com/forums/showthread.php?t=24538 > Steve > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From fvzwieten at vxcompany.com Fri Oct 5 17:36:53 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 5 Oct 2012 19:36:53 +0200 Subject: [Freeipa-users] Query IPA for group membership Message-ID: Hello, I have a IPA server running. This server has users who are member to various groups. I want to query the IPA server from an IPA client to know whether a user is a member to a group. I want to do this from the OpenVPN service using the openvpn_auth_pam.so. Normally one uses this like this: openvpn_auth_pam.so login This queries the PAM login (and thus IPA) is the username/password from openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs say you could use other modules instead of login. So, I would like to add the next line: openvpn_auth_pam.so group "openvpn" Where a /etc/pam.d/group file would check whether the user is member of the group "openvpn". If not, false is returned and the login attempt (thru openvpn) fails. Is this possible? If not is there a better way? Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 5 17:50:53 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Oct 2012 13:50:53 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: Message-ID: <506F1DFD.8050602@redhat.com> On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > Hello, > > I have a IPA server running. This server has users who are member to > various groups. I want to query the IPA server from an IPA client to > know whether a user is a member to a group. > > I want to do this from the OpenVPN service using the > openvpn_auth_pam.so. Normally one uses this like this: > > openvpn_auth_pam.so login > > This queries the PAM login (and thus IPA) is the username/password > from openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs > say you could use other modules instead of login. > > So, I would like to add the next line: > > openvpn_auth_pam.so group "openvpn" > > Where a /etc/pam.d/group file would check whether the user is member > of the group "openvpn". If not, false is returned and the login > attempt (thru openvpn) fails. > > Is this possible? If not is there a better way? > > Fred Can you step up from the implementation and explain what you want to accomplish? It seems that you want to use OpenVPN and do some access control checks when user connects to OpenVPN. Right? If you can describe the flow of operations we might be able guide you to the right solution. Also would be nice to understand what OS OpenVPN is running on. > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Oct 5 18:03:13 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 14:03:13 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <506F1DFD.8050602@redhat.com> References: <506F1DFD.8050602@redhat.com> Message-ID: <1349460193.26127.26.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 13:50 -0400, Dmitri Pal wrote: > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > > Hello, > > > > > > I have a IPA server running. This server has users who are member to > > various groups. I want to query the IPA server from an IPA client to > > know whether a user is a member to a group. > > > > > > I want to do this from the OpenVPN service using the > > openvpn_auth_pam.so. Normally one uses this like this: > > > > > > openvpn_auth_pam.so login > > > > > > This queries the PAM login (and thus IPA) is the username/password > > from openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs > > say you could use other modules instead of login. > > > > > > So, I would like to add the next line: > > > > > > openvpn_auth_pam.so group "openvpn" > > > > > > Where a /etc/pam.d/group file would check whether the user is member > > of the group "openvpn". If not, false is returned and the login > > attempt (thru openvpn) fails. > > > > > > Is this possible? If not is there a better way? > > > > > > Fred > > > Can you step up from the implementation and explain what you want to > accomplish? > It seems that you want to use OpenVPN and do some access control > checks when user connects to OpenVPN. Right? > If you can describe the flow of operations we might be able guide you > to the right solution. > > Also would be nice to understand what OS OpenVPN is running on. If the PAM stack is used fully (account phase at least) then HBAC may be a better way to do this sort of check. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Oct 5 18:04:39 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Oct 2012 14:04:39 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <1349460193.26127.26.camel@willson.li.ssimo.org> References: <506F1DFD.8050602@redhat.com> <1349460193.26127.26.camel@willson.li.ssimo.org> Message-ID: <506F2137.3020203@redhat.com> On 10/05/2012 02:03 PM, Simo Sorce wrote: > On Fri, 2012-10-05 at 13:50 -0400, Dmitri Pal wrote: >> On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >>> Hello, >>> >>> >>> I have a IPA server running. This server has users who are member to >>> various groups. I want to query the IPA server from an IPA client to >>> know whether a user is a member to a group. >>> >>> >>> I want to do this from the OpenVPN service using the >>> openvpn_auth_pam.so. Normally one uses this like this: >>> >>> >>> openvpn_auth_pam.so login >>> >>> >>> This queries the PAM login (and thus IPA) is the username/password >>> from openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs >>> say you could use other modules instead of login. >>> >>> >>> So, I would like to add the next line: >>> >>> >>> openvpn_auth_pam.so group "openvpn" >>> >>> >>> Where a /etc/pam.d/group file would check whether the user is member >>> of the group "openvpn". If not, false is returned and the login >>> attempt (thru openvpn) fails. >>> >>> >>> Is this possible? If not is there a better way? >>> >>> >>> Fred >> >> Can you step up from the implementation and explain what you want to >> accomplish? >> It seems that you want to use OpenVPN and do some access control >> checks when user connects to OpenVPN. Right? >> If you can describe the flow of operations we might be able guide you >> to the right solution. >> >> Also would be nice to understand what OS OpenVPN is running on. > If the PAM stack is used fully (account phase at least) then HBAC may be > a better way to do this sort of check. > > Simo. > Yes I was thinking about it but this might not be version of Linux where SSSD is not available. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From fvzwieten at vxcompany.com Fri Oct 5 18:13:48 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 5 Oct 2012 20:13:48 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <506F1DFD.8050602@redhat.com> References: <506F1DFD.8050602@redhat.com> Message-ID: You are completely right :-) Both IPA server and client are RHEL6.3 x86_64 boxes. On the OpenVPN server (which is an IPA client), I have 2 OpenVPN instances running, because different users must end up in different subnet's OpenVPN instance 1 listens on port 50000 OpenVPN instance 2 listens on port 50001 Users for subnet 1 must connect and authenticate on instance 1 (and get an IP in subnet 1) Users for subnet 2 must connect and authenticate on instance 2 (and get an IP in subnet 2) Both OpenVPN instances use the login pam module. In this setup I can not prevent users for subnet 2 to connect and authenticate successfully on OpenVPN instance 1. So, I would like to put the users for OpenVPN instance 1 in group OpenVPN1 en users for OpenVPN instance 2 in group OpenVPN2 on IPA. Next, the OpenVPN daemon must be able to check a user for membership. Is it is not a member, false is returned, and the OpenVMN authentication fails. Documentation for the openvpn_auth_pam is here . Fred On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal wrote: > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > > Hello, > > I have a IPA server running. This server has users who are member to > various groups. I want to query the IPA server from an IPA client to know > whether a user is a member to a group. > > I want to do this from the OpenVPN service using the > openvpn_auth_pam.so. Normally one uses this like this: > > openvpn_auth_pam.so login > > This queries the PAM login (and thus IPA) is the username/password from > openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs say you > could use other modules instead of login. > > So, I would like to add the next line: > > openvpn_auth_pam.so group "openvpn" > > Where a /etc/pam.d/group file would check whether the user is member of > the group "openvpn". If not, false is returned and the login attempt (thru > openvpn) fails. > > Is this possible? If not is there a better way? > > Fred > > > > Can you step up from the implementation and explain what you want to > accomplish? > It seems that you want to use OpenVPN and do some access control checks > when user connects to OpenVPN. Right? > If you can describe the flow of operations we might be able guide you to > the right solution. > > Also would be nice to understand what OS OpenVPN is running on. > > > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 5 18:23:56 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 05 Oct 2012 14:23:56 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> Message-ID: <506F25BC.5050104@redhat.com> On 10/05/2012 02:13 PM, Fred van Zwieten wrote: > You are completely right :-) > > Both IPA server and client are RHEL6.3 x86_64 boxes. > > On the OpenVPN server (which is an IPA client), I have 2 OpenVPN > instances running, because different users must end up in different > subnet's > > OpenVPN instance 1 listens on port 50000 > OpenVPN instance 2 listens on port 50001 > > Users for subnet 1 must connect and authenticate on instance 1 (and > get an IP in subnet 1) > Users for subnet 2 must connect and authenticate on instance 2 (and > get an IP in subnet 2) > > Both OpenVPN instances use the login pam module. > > In this setup I can not prevent users for subnet 2 to connect and > authenticate successfully on OpenVPN instance 1. > > So, I would like to put the users for OpenVPN instance 1 in group > OpenVPN1 en users for OpenVPN instance 2 in group OpenVPN2 on IPA. > > Next, the OpenVPN daemon must be able to check a user for membership. > Is it is not a member, false is returned, and the OpenVMN > authentication fails. > > Documentation for the openvpn_auth_pam is here > . > OK, makes sense. How does you pam configuration look like? Especially the accounting part? What modules do you have there? Can it be PAM module you are using expecting some value that need to be configured in openvpn_auth_pam config? > Fred > > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal > wrote: > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >> Hello, >> >> I have a IPA server running. This server has users who are member >> to various groups. I want to query the IPA server from an IPA >> client to know whether a user is a member to a group. >> >> I want to do this from the OpenVPN service using the >> openvpn_auth_pam.so. Normally one uses this like this: >> >> openvpn_auth_pam.so login >> >> This queries the PAM login (and thus IPA) is the >> username/password from openvpn is valid. the "login" is >> /etc/pam.d/login. OpenVPN docs say you could use other modules >> instead of login. >> >> So, I would like to add the next line: >> >> openvpn_auth_pam.so group "openvpn" >> >> Where a /etc/pam.d/group file would check whether the user is >> member of the group "openvpn". If not, false is returned and the >> login attempt (thru openvpn) fails. >> >> Is this possible? If not is there a better way? >> >> Fred > > > Can you step up from the implementation and explain what you want > to accomplish? > It seems that you want to use OpenVPN and do some access control > checks when user connects to OpenVPN. Right? > If you can describe the flow of operations we might be able guide > you to the right solution. > > Also would be nice to understand what OS OpenVPN is running on. > >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Oct 5 18:24:54 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 14:24:54 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> Message-ID: <1349461494.26127.28.camel@willson.li.ssimo.org> On Fri, 2012-10-05 at 20:13 +0200, Fred van Zwieten wrote: > You are completely right :-) > > > Both IPA server and client are RHEL6.3 x86_64 boxes. > > > On the OpenVPN server (which is an IPA client), I have 2 OpenVPN > instances running, because different users must end up in different > subnet's > > > OpenVPN instance 1 listens on port 50000 > OpenVPN instance 2 listens on port 50001 > > > Users for subnet 1 must connect and authenticate on instance 1 (and > get an IP in subnet 1) > Users for subnet 2 must connect and authenticate on instance 2 (and > get an IP in subnet 2) > > > Both OpenVPN instances use the login pam module. > > > In this setup I can not prevent users for subnet 2 to connect and > authenticate successfully on OpenVPN instance 1. > > > So, I would like to put the users for OpenVPN instance 1 in group > OpenVPN1 en users for OpenVPN instance 2 in group OpenVPN2 on IPA. > > > Next, the OpenVPN daemon must be able to check a user for membership. > Is it is not a member, false is returned, and the OpenVMN > authentication fails. > > > Documentation for the openvpn_auth_pam is here. > Fred, what you can do is to use different pams ervice names (if openvpn allows you to do that). Create 2 services openvpn1 and openvpn2 and the use HBAC to assign appropriate access control to those service for the openvpn concentrator. Simo. -- Simo Sorce * Red Hat, Inc * New York From sbingram at gmail.com Fri Oct 5 18:54:45 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Fri, 5 Oct 2012 11:54:45 -0700 Subject: [Freeipa-users] saslauthd on freeipa machine In-Reply-To: <506F12E6.8020706@redhat.com> References: <506F12E6.8020706@redhat.com> Message-ID: On Fri, Oct 5, 2012 at 10:03 AM, Dmitri Pal wrote: > On 10/05/2012 12:16 PM, Stephen Ingram wrote: >> As I typically have saslauthd use kerberos to authenticate users I >> really haven't had the occasion to try before. Since freeipa machines >> use SSSD to help manage users on the system, I thought that saslauthd >> should be able to authenticate users against PAM as well. Unless I >> have somehow misconfigured, this seems not to be the case as each time >> I get: >> >> saslauthd[7342] :do_auth : auth failure: [user=nancy] >> [service=smtp] [realm=] [mech=pam] [reason=PAM acct error] >> >> According to the logs on the freeipa machine, the auth is correct and >> the ticket is issued. Is there some additional client configuration >> required to make this work since SSSD now involved? > This seems relevant: > http://www.howtoforge.com/forums/showthread.php?t=24538 Thanks. Just to follow up, it does work out of the box. I neglected to tell IPA HBAC to let me on that host. Needless to say, if you are going to use IPA, you need to use IPA **correctly**! Steve From fvzwieten at vxcompany.com Fri Oct 5 18:58:31 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 5 Oct 2012 20:58:31 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <506F25BC.5050104@redhat.com> References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> Message-ID: Dmitri, Well, this is, sort of, the point. I have no experience using pam, so I have no idea how to set this up. I have authentication up and running, but, like I said, both OpenVPN instances happily authenticate users from both groups of users. In my openvpn config file i have: plugin openvpn_auth_pam login where login is the /etc/pam.d/login file. I have not adjusted this file. This is standard file for IPA client. So, my idea was to do this in openvpn config file: plugin openvpn_auth_pam login (can the user authenticate y/n?) plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is the user member op OPENVPN1 y/n?) plugin openvpn_auth_pam is afaik the only way to get OpenVPN to authenticate against IPA. I am not sure how this could be setup to work with HBAC.. Fred On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: > > You are completely right :-) > > Both IPA server and client are RHEL6.3 x86_64 boxes. > > On the OpenVPN server (which is an IPA client), I have 2 OpenVPN > instances running, because different users must end up in different subnet's > > OpenVPN instance 1 listens on port 50000 > OpenVPN instance 2 listens on port 50001 > > Users for subnet 1 must connect and authenticate on instance 1 (and get > an IP in subnet 1) > Users for subnet 2 must connect and authenticate on instance 2 (and get an > IP in subnet 2) > > Both OpenVPN instances use the login pam module. > > In this setup I can not prevent users for subnet 2 to connect and > authenticate successfully on OpenVPN instance 1. > > So, I would like to put the users for OpenVPN instance 1 in group > OpenVPN1 en users for OpenVPN instance 2 in group OpenVPN2 on IPA. > > Next, the OpenVPN daemon must be able to check a user for membership. Is > it is not a member, false is returned, and the OpenVMN authentication fails. > > Documentation for the openvpn_auth_pam is here > . > > > OK, makes sense. > How does you pam configuration look like? > Especially the accounting part? What modules do you have there? > Can it be PAM module you are using expecting some value that need to be > configured in openvpn_auth_pam config? > > Fred > > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal wrote: > >> On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >> >> Hello, >> >> I have a IPA server running. This server has users who are member to >> various groups. I want to query the IPA server from an IPA client to know >> whether a user is a member to a group. >> >> I want to do this from the OpenVPN service using the >> openvpn_auth_pam.so. Normally one uses this like this: >> >> openvpn_auth_pam.so login >> >> This queries the PAM login (and thus IPA) is the username/password from >> openvpn is valid. the "login" is /etc/pam.d/login. OpenVPN docs say you >> could use other modules instead of login. >> >> So, I would like to add the next line: >> >> openvpn_auth_pam.so group "openvpn" >> >> Where a /etc/pam.d/group file would check whether the user is member of >> the group "openvpn". If not, false is returned and the login attempt (thru >> openvpn) fails. >> >> Is this possible? If not is there a better way? >> >> Fred >> >> >> >> Can you step up from the implementation and explain what you want to >> accomplish? >> It seems that you want to use OpenVPN and do some access control checks >> when user connects to OpenVPN. Right? >> If you can describe the flow of operations we might be able guide you to >> the right solution. >> >> Also would be nice to understand what OS OpenVPN is running on. >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager for IdM portfolio >> Red Hat Inc. >> >> >> ------------------------------- >> Looking to carve out IT costs?www.redhat.com/carveoutcosts/ >> >> > > > _______________________________________________ > Freeipa-users mailing listFreeipa-users at redhat.comhttps://www.redhat.com/mailman/listinfo/freeipa-users > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs?www.redhat.com/carveoutcosts/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Oct 5 19:09:15 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 05 Oct 2012 15:09:15 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> Message-ID: <1349464155.26127.36.camel@willson.li.ssimo.org> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and openvn2 Then configure the two instance instance with: plugin openvpn_auth_pam openvpn1 and plugin openvpn_auth_pam openvpn2 respectively. Then you can create HBAC rules in IPA using openvpn1 and openvon2 as service names. Simo. On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: > Dmitri, > > > Well, this is, sort of, the point. I have no experience using pam, so > I have no idea how to set this up. > > > I have authentication up and running, but, like I said, both OpenVPN > instances happily authenticate users from both groups of users. > > > In my openvpn config file i have: > > > plugin openvpn_auth_pam login > > > where login is the /etc/pam.d/login file. I have not adjusted this > file. This is standard file for IPA client. > > > So, my idea was to do this in openvpn config file: > > > plugin openvpn_auth_pam login (can the user authenticate y/n?) > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is > the user member op OPENVPN1 y/n?) > > > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to > authenticate against IPA. I am not sure how this could be setup to > work with HBAC.. > > > Fred > > > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: > > You are completely right :-) > > > > > > Both IPA server and client are RHEL6.3 x86_64 boxes. > > > > > > On the OpenVPN server (which is an IPA client), I have 2 > > OpenVPN instances running, because different users must end > > up in different subnet's > > > > > > OpenVPN instance 1 listens on port 50000 > > OpenVPN instance 2 listens on port 50001 > > > > > > Users for subnet 1 must connect and authenticate on instance > > 1 (and get an IP in subnet 1) > > Users for subnet 2 must connect and authenticate on instance > > 2 (and get an IP in subnet 2) > > > > > > Both OpenVPN instances use the login pam module. > > > > > > In this setup I can not prevent users for subnet 2 to > > connect and authenticate successfully on OpenVPN instance 1. > > > > > > So, I would like to put the users for OpenVPN instance 1 in > > group OpenVPN1 en users for OpenVPN instance 2 in group > > OpenVPN2 on IPA. > > > > > > Next, the OpenVPN daemon must be able to check a user for > > membership. Is it is not a member, false is returned, and > > the OpenVMN authentication fails. > > > > > > Documentation for the openvpn_auth_pam is here. > > > > > > > OK, makes sense. > How does you pam configuration look like? > Especially the accounting part? What modules do you have > there? > Can it be PAM module you are using expecting some value that > need to be configured in openvpn_auth_pam config? > > > Fred > > > > > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal > > wrote: > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > > > Hello, > > > > > > > > > I have a IPA server running. This server has users > > > who are member to various groups. I want to query > > > the IPA server from an IPA client to know whether > > > a user is a member to a group. > > > > > > > > > I want to do this from the OpenVPN service using > > > the openvpn_auth_pam.so. Normally one uses this > > > like this: > > > > > > > > > openvpn_auth_pam.so login > > > > > > > > > This queries the PAM login (and thus IPA) is the > > > username/password from openvpn is valid. the > > > "login" is /etc/pam.d/login. OpenVPN docs say you > > > could use other modules instead of login. > > > > > > > > > So, I would like to add the next line: > > > > > > > > > openvpn_auth_pam.so group "openvpn" > > > > > > > > > Where a /etc/pam.d/group file would check whether > > > the user is member of the group "openvpn". If not, > > > false is returned and the login attempt (thru > > > openvpn) fails. > > > > > > > > > Is this possible? If not is there a better way? > > > > > > > > > Fred > > > > > > > > Can you step up from the implementation and explain > > what you want to accomplish? > > It seems that you want to use OpenVPN and do some > > access control checks when user connects to OpenVPN. > > Right? > > If you can describe the flow of operations we might > > be able guide you to the right solution. > > > > Also would be nice to understand what OS OpenVPN is > > running on. > > > > > > > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Simo Sorce * Red Hat, Inc * New York From fvzwieten at vxcompany.com Fri Oct 5 19:18:16 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Fri, 5 Oct 2012 21:18:16 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <1349464155.26127.36.camel@willson.li.ssimo.org> References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> Message-ID: Simo, That sounds easy enough. I will test it asap when I get to work on monday and let you know. Thank you (and Dmitri) so far and have a good weekend. Fred On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce wrote: > > Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and > openvn2 > > Then configure the two instance instance with: > plugin openvpn_auth_pam openvpn1 > and > plugin openvpn_auth_pam openvpn2 > respectively. > > Then you can create HBAC rules in IPA using openvpn1 and openvon2 as > service names. > > Simo. > > On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: > > Dmitri, > > > > > > Well, this is, sort of, the point. I have no experience using pam, so > > I have no idea how to set this up. > > > > > > I have authentication up and running, but, like I said, both OpenVPN > > instances happily authenticate users from both groups of users. > > > > > > In my openvpn config file i have: > > > > > > plugin openvpn_auth_pam login > > > > > > where login is the /etc/pam.d/login file. I have not adjusted this > > file. This is standard file for IPA client. > > > > > > So, my idea was to do this in openvpn config file: > > > > > > plugin openvpn_auth_pam login (can the user authenticate y/n?) > > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is > > the user member op OPENVPN1 y/n?) > > > > > > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to > > authenticate against IPA. I am not sure how this could be setup to > > work with HBAC.. > > > > > > Fred > > > > > > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: > > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: > > > You are completely right :-) > > > > > > > > > Both IPA server and client are RHEL6.3 x86_64 boxes. > > > > > > > > > On the OpenVPN server (which is an IPA client), I have 2 > > > OpenVPN instances running, because different users must end > > > up in different subnet's > > > > > > > > > OpenVPN instance 1 listens on port 50000 > > > OpenVPN instance 2 listens on port 50001 > > > > > > > > > Users for subnet 1 must connect and authenticate on instance > > > 1 (and get an IP in subnet 1) > > > Users for subnet 2 must connect and authenticate on instance > > > 2 (and get an IP in subnet 2) > > > > > > > > > Both OpenVPN instances use the login pam module. > > > > > > > > > In this setup I can not prevent users for subnet 2 to > > > connect and authenticate successfully on OpenVPN instance 1. > > > > > > > > > So, I would like to put the users for OpenVPN instance 1 in > > > group OpenVPN1 en users for OpenVPN instance 2 in group > > > OpenVPN2 on IPA. > > > > > > > > > Next, the OpenVPN daemon must be able to check a user for > > > membership. Is it is not a member, false is returned, and > > > the OpenVMN authentication fails. > > > > > > > > > Documentation for the openvpn_auth_pam is here. > > > > > > > > > > > > OK, makes sense. > > How does you pam configuration look like? > > Especially the accounting part? What modules do you have > > there? > > Can it be PAM module you are using expecting some value that > > need to be configured in openvpn_auth_pam config? > > > > > Fred > > > > > > > > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal > > > wrote: > > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > > > > Hello, > > > > > > > > > > > > I have a IPA server running. This server has users > > > > who are member to various groups. I want to query > > > > the IPA server from an IPA client to know whether > > > > a user is a member to a group. > > > > > > > > > > > > I want to do this from the OpenVPN service using > > > > the openvpn_auth_pam.so. Normally one uses this > > > > like this: > > > > > > > > > > > > openvpn_auth_pam.so login > > > > > > > > > > > > This queries the PAM login (and thus IPA) is the > > > > username/password from openvpn is valid. the > > > > "login" is /etc/pam.d/login. OpenVPN docs say you > > > > could use other modules instead of login. > > > > > > > > > > > > So, I would like to add the next line: > > > > > > > > > > > > openvpn_auth_pam.so group "openvpn" > > > > > > > > > > > > Where a /etc/pam.d/group file would check whether > > > > the user is member of the group "openvpn". If not, > > > > false is returned and the login attempt (thru > > > > openvpn) fails. > > > > > > > > > > > > Is this possible? If not is there a better way? > > > > > > > > > > > > Fred > > > > > > > > > > > > Can you step up from the implementation and explain > > > what you want to accomplish? > > > It seems that you want to use OpenVPN and do some > > > access control checks when user connects to OpenVPN. > > > Right? > > > If you can describe the flow of operations we might > > > be able guide you to the right solution. > > > > > > Also would be nice to understand what OS OpenVPN is > > > running on. > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > Freeipa-users mailing list > > > > Freeipa-users at redhat.com > > > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager for IdM portfolio > > > Red Hat Inc. > > > > > > > > > ------------------------------- > > > Looking to carve out IT costs? > > > www.redhat.com/carveoutcosts/ > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > Freeipa-users mailing list > > > Freeipa-users at redhat.com > > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager for IdM portfolio > > Red Hat Inc. > > > > > > ------------------------------- > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Sat Oct 6 06:12:58 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 6 Oct 2012 08:12:58 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> Message-ID: Hang on..I don't see how this can work (I haven't tried it btw). If I simply copy login to openvpn1 and call openvpn_auth_pam with that file as a parameter, how can it magically know to query IPA for the openvpn1 service as opposed to username/password? Must I not change the openvpn1 file to have it check for the service? Fred > > > On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce wrote: > >> >> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and >> openvn2 >> >> Then configure the two instance instance with: >> plugin openvpn_auth_pam openvpn1 >> and >> plugin openvpn_auth_pam openvpn2 >> respectively. >> >> Then you can create HBAC rules in IPA using openvpn1 and openvon2 as >> service names. >> >> Simo. >> >> On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: >> > Dmitri, >> > >> > >> > Well, this is, sort of, the point. I have no experience using pam, so >> > I have no idea how to set this up. >> > >> > >> > I have authentication up and running, but, like I said, both OpenVPN >> > instances happily authenticate users from both groups of users. >> > >> > >> > In my openvpn config file i have: >> > >> > >> > plugin openvpn_auth_pam login >> > >> > >> > where login is the /etc/pam.d/login file. I have not adjusted this >> > file. This is standard file for IPA client. >> > >> > >> > So, my idea was to do this in openvpn config file: >> > >> > >> > plugin openvpn_auth_pam login (can the user authenticate y/n?) >> > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is >> > the user member op OPENVPN1 y/n?) >> > >> > >> > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to >> > authenticate against IPA. I am not sure how this could be setup to >> > work with HBAC.. >> > >> > >> > Fred >> > >> > >> > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: >> > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: >> > > You are completely right :-) >> > > >> > > >> > > Both IPA server and client are RHEL6.3 x86_64 boxes. >> > > >> > > >> > > On the OpenVPN server (which is an IPA client), I have 2 >> > > OpenVPN instances running, because different users must end >> > > up in different subnet's >> > > >> > > >> > > OpenVPN instance 1 listens on port 50000 >> > > OpenVPN instance 2 listens on port 50001 >> > > >> > > >> > > Users for subnet 1 must connect and authenticate on instance >> > > 1 (and get an IP in subnet 1) >> > > Users for subnet 2 must connect and authenticate on instance >> > > 2 (and get an IP in subnet 2) >> > > >> > > >> > > Both OpenVPN instances use the login pam module. >> > > >> > > >> > > In this setup I can not prevent users for subnet 2 to >> > > connect and authenticate successfully on OpenVPN instance 1. >> > > >> > > >> > > So, I would like to put the users for OpenVPN instance 1 in >> > > group OpenVPN1 en users for OpenVPN instance 2 in group >> > > OpenVPN2 on IPA. >> > > >> > > >> > > Next, the OpenVPN daemon must be able to check a user for >> > > membership. Is it is not a member, false is returned, and >> > > the OpenVMN authentication fails. >> > > >> > > >> > > Documentation for the openvpn_auth_pam is here. >> > > >> > > >> > >> > >> > OK, makes sense. >> > How does you pam configuration look like? >> > Especially the accounting part? What modules do you have >> > there? >> > Can it be PAM module you are using expecting some value that >> > need to be configured in openvpn_auth_pam config? >> > >> > > Fred >> > > >> > > >> > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal >> > > wrote: >> > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >> > > > Hello, >> > > > >> > > > >> > > > I have a IPA server running. This server has users >> > > > who are member to various groups. I want to query >> > > > the IPA server from an IPA client to know whether >> > > > a user is a member to a group. >> > > > >> > > > >> > > > I want to do this from the OpenVPN service using >> > > > the openvpn_auth_pam.so. Normally one uses this >> > > > like this: >> > > > >> > > > >> > > > openvpn_auth_pam.so login >> > > > >> > > > >> > > > This queries the PAM login (and thus IPA) is the >> > > > username/password from openvpn is valid. the >> > > > "login" is /etc/pam.d/login. OpenVPN docs say you >> > > > could use other modules instead of login. >> > > > >> > > > >> > > > So, I would like to add the next line: >> > > > >> > > > >> > > > openvpn_auth_pam.so group "openvpn" >> > > > >> > > > >> > > > Where a /etc/pam.d/group file would check whether >> > > > the user is member of the group "openvpn". If not, >> > > > false is returned and the login attempt (thru >> > > > openvpn) fails. >> > > > >> > > > >> > > > Is this possible? If not is there a better way? >> > > > >> > > > >> > > > Fred >> > > >> > > >> > > >> > > Can you step up from the implementation and explain >> > > what you want to accomplish? >> > > It seems that you want to use OpenVPN and do some >> > > access control checks when user connects to OpenVPN. >> > > Right? >> > > If you can describe the flow of operations we might >> > > be able guide you to the right solution. >> > > >> > > Also would be nice to understand what OS OpenVPN is >> > > running on. >> > > >> > > > >> > > > >> > > > >> > > > >> > > > _______________________________________________ >> > > > Freeipa-users mailing list >> > > > Freeipa-users at redhat.com >> > > > >> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > >> > > >> > > -- >> > > Thank you, >> > > Dmitri Pal >> > > >> > > Sr. Engineering Manager for IdM portfolio >> > > Red Hat Inc. >> > > >> > > >> > > ------------------------------- >> > > Looking to carve out IT costs? >> > > www.redhat.com/carveoutcosts/ >> > > >> > > >> > > >> > > >> > > >> > > >> > > _______________________________________________ >> > > Freeipa-users mailing list >> > > Freeipa-users at redhat.com >> > > https://www.redhat.com/mailman/listinfo/freeipa-users >> > >> > >> > -- >> > Thank you, >> > Dmitri Pal >> > >> > Sr. Engineering Manager for IdM portfolio >> > Red Hat Inc. >> > >> > >> > ------------------------------- >> > Looking to carve out IT costs? >> > www.redhat.com/carveoutcosts/ >> > >> > >> > >> > >> > _______________________________________________ >> > Freeipa-users mailing list >> > Freeipa-users at redhat.com >> > https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Sat Oct 6 18:31:07 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Sat, 6 Oct 2012 21:31:07 +0300 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> Message-ID: <20121006183107.GZ17454@redhat.com> On Sat, 06 Oct 2012, Fred van Zwieten wrote: >Hang on..I don't see how this can work (I haven't tried it btw). > >If I simply copy login to openvpn1 and call openvpn_auth_pam with that file >as a parameter, how can it magically know to query IPA for the openvpn1 >service as opposed to username/password? Must I not change the openvpn1 >file to have it check for the service? PAM defines a 'service', equal to the name of /etc/pam.d/ file. An application using PAM starts using PAM functions by defining what service it will be, then PAM code load definitions of the service from the /etc/pam.d/ file and process them accordingly and apply them in appropriate stages (authentication, account management, session management, password checks). If your IPA hosts use SSSD daemon (default), then your PAM stack by default is configured to authenticate against IPA server and use of its features like Host-based access control (HBAC). You can verify it by checking /etc/pam.d/system-auth (login PAM service includes this file). Let's say, you want to define PAM services 'ovpn_group1' and 'ovpn_group2' that actually use login PAM service. You can do it following way: cd /etc/pam.d ln -s login ovpn_group1 ln -s login ovpn_group2 Now you have two configuration files named 'ovpn_group1' and 'ovpn_group2', you need to allow their use in both OpenVPN and in IPA to limit who can get into use of the service. On OpenVPN side you'd have two configuration files and set plugin openvpn-auth-pam.so ovpn_group1 in the first configuration file and plugin openvpn-auth-pam.so ovpn_group2 in the second. You don't need to add 'check_group' as the check would be done automatically by pam_sss module using HBAC rules from IPA. In IPA you can define HBAC services corresponding to those files. We have predefined some of them, for commonly available on the machines, but you can expand that list. Go to 'Policy -> Host Base Acces Control -> HBAC Services' and add two services there, 'ovpn_group1' and 'ovpn_group2'. Next, define HBAC rules that reference the services ovpn_group1 and ovpn_group2. Put appropriate groups in the rules as to what users would be allowed to access them (and on which hosts). You need to be aware that IPA HBAC rules are explicit. If there is no rule that allows access, it is denied. By default there is one rule called 'allow_all' which is enabled, so access is allowed from any user to any service on any host. Once you start using explicit HBAC rules, you'll need to define all of them and then disable 'allow_all' rule because otherwise it will always match and grant access. Here is how this difference is visible. I defined one PAM service, 'test-service' by doing a symlink to login service file and used a simple program https://github.com/beatgammit/simple-pam/blob/master/src/test.c to test. The program simply initializes PAM stack for specified service ('check_user' in the source above, I only replaced that by 'test-service' in my copy) and then runs a sequence of calls, like any PAM-enabled application should do (except handling password expiration, but that is detail here). I have defined special HBAC rule in IPA that only allowed users from a group 'test' to use service 'test-service'. User admin does not belong to that group, user ab does belong to it. First with 'allow_all' rule enabled by default: -sh-4.2$ ./app admin Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ ./app ab Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ Now I disabled 'allow_all' rule in the IPA web UI: $ ./app admin Credentials accepted. Password: Account is valid. Not Authenticated -sh-4.2$ ./app ab Credentials accepted. Password: Account is valid. Authenticated -sh-4.2$ You'll see following in the /var/log/secure when 'allow_all' is disabled: ... Oct 6 21:16:06 head app: pam_sss(test-service:auth): authentication success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=admin Oct 6 21:16:06 head app: pam_sss(test-service:account): Access denied for user admin: 6 (Permission denied) ... Oct 6 21:17:43 head app: pam_unix(test-service:auth): authentication failure; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=ab Oct 6 21:17:46 head app: pam_sss(test-service:auth): authentication success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= user=ab Authentication went successfully (admin credentials were accepted) but then account management part of pam_sss applied HBAC rules and found out that none of the rules was matched, the access was denied. That's it, start your OpenVPN instances and they should be able to log-in only those users who pass HBAC rules for their specific PAM services. >Fred > >> >> >> On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce wrote: >> >>> >>> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and >>> openvn2 >>> >>> Then configure the two instance instance with: >>> plugin openvpn_auth_pam openvpn1 >>> and >>> plugin openvpn_auth_pam openvpn2 >>> respectively. >>> >>> Then you can create HBAC rules in IPA using openvpn1 and openvon2 as >>> service names. >>> >>> Simo. >>> >>> On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: >>> > Dmitri, >>> > >>> > >>> > Well, this is, sort of, the point. I have no experience using pam, so >>> > I have no idea how to set this up. >>> > >>> > >>> > I have authentication up and running, but, like I said, both OpenVPN >>> > instances happily authenticate users from both groups of users. >>> > >>> > >>> > In my openvpn config file i have: >>> > >>> > >>> > plugin openvpn_auth_pam login >>> > >>> > >>> > where login is the /etc/pam.d/login file. I have not adjusted this >>> > file. This is standard file for IPA client. >>> > >>> > >>> > So, my idea was to do this in openvpn config file: >>> > >>> > >>> > plugin openvpn_auth_pam login (can the user authenticate y/n?) >>> > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is >>> > the user member op OPENVPN1 y/n?) >>> > >>> > >>> > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to >>> > authenticate against IPA. I am not sure how this could be setup to >>> > work with HBAC.. >>> > >>> > >>> > Fred >>> > >>> > >>> > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: >>> > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: >>> > > You are completely right :-) >>> > > >>> > > >>> > > Both IPA server and client are RHEL6.3 x86_64 boxes. >>> > > >>> > > >>> > > On the OpenVPN server (which is an IPA client), I have 2 >>> > > OpenVPN instances running, because different users must end >>> > > up in different subnet's >>> > > >>> > > >>> > > OpenVPN instance 1 listens on port 50000 >>> > > OpenVPN instance 2 listens on port 50001 >>> > > >>> > > >>> > > Users for subnet 1 must connect and authenticate on instance >>> > > 1 (and get an IP in subnet 1) >>> > > Users for subnet 2 must connect and authenticate on instance >>> > > 2 (and get an IP in subnet 2) >>> > > >>> > > >>> > > Both OpenVPN instances use the login pam module. >>> > > >>> > > >>> > > In this setup I can not prevent users for subnet 2 to >>> > > connect and authenticate successfully on OpenVPN instance 1. >>> > > >>> > > >>> > > So, I would like to put the users for OpenVPN instance 1 in >>> > > group OpenVPN1 en users for OpenVPN instance 2 in group >>> > > OpenVPN2 on IPA. >>> > > >>> > > >>> > > Next, the OpenVPN daemon must be able to check a user for >>> > > membership. Is it is not a member, false is returned, and >>> > > the OpenVMN authentication fails. >>> > > >>> > > >>> > > Documentation for the openvpn_auth_pam is here. >>> > > >>> > > >>> > >>> > >>> > OK, makes sense. >>> > How does you pam configuration look like? >>> > Especially the accounting part? What modules do you have >>> > there? >>> > Can it be PAM module you are using expecting some value that >>> > need to be configured in openvpn_auth_pam config? >>> > >>> > > Fred >>> > > >>> > > >>> > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal >>> > > wrote: >>> > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >>> > > > Hello, >>> > > > >>> > > > >>> > > > I have a IPA server running. This server has users >>> > > > who are member to various groups. I want to query >>> > > > the IPA server from an IPA client to know whether >>> > > > a user is a member to a group. >>> > > > >>> > > > >>> > > > I want to do this from the OpenVPN service using >>> > > > the openvpn_auth_pam.so. Normally one uses this >>> > > > like this: >>> > > > >>> > > > >>> > > > openvpn_auth_pam.so login >>> > > > >>> > > > >>> > > > This queries the PAM login (and thus IPA) is the >>> > > > username/password from openvpn is valid. the >>> > > > "login" is /etc/pam.d/login. OpenVPN docs say you >>> > > > could use other modules instead of login. >>> > > > >>> > > > >>> > > > So, I would like to add the next line: >>> > > > >>> > > > >>> > > > openvpn_auth_pam.so group "openvpn" >>> > > > >>> > > > >>> > > > Where a /etc/pam.d/group file would check whether >>> > > > the user is member of the group "openvpn". If not, >>> > > > false is returned and the login attempt (thru >>> > > > openvpn) fails. >>> > > > >>> > > > >>> > > > Is this possible? If not is there a better way? >>> > > > >>> > > > >>> > > > Fred >>> > > >>> > > >>> > > >>> > > Can you step up from the implementation and explain >>> > > what you want to accomplish? >>> > > It seems that you want to use OpenVPN and do some >>> > > access control checks when user connects to OpenVPN. >>> > > Right? >>> > > If you can describe the flow of operations we might >>> > > be able guide you to the right solution. >>> > > >>> > > Also would be nice to understand what OS OpenVPN is >>> > > running on. >>> > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > _______________________________________________ >>> > > > Freeipa-users mailing list >>> > > > Freeipa-users at redhat.com >>> > > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> > > >>> > > >>> > > -- >>> > > Thank you, >>> > > Dmitri Pal >>> > > >>> > > Sr. Engineering Manager for IdM portfolio >>> > > Red Hat Inc. >>> > > >>> > > >>> > > ------------------------------- >>> > > Looking to carve out IT costs? >>> > > www.redhat.com/carveoutcosts/ >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > Freeipa-users mailing list >>> > > Freeipa-users at redhat.com >>> > > https://www.redhat.com/mailman/listinfo/freeipa-users >>> > >>> > >>> > -- >>> > Thank you, >>> > Dmitri Pal >>> > >>> > Sr. Engineering Manager for IdM portfolio >>> > Red Hat Inc. >>> > >>> > >>> > ------------------------------- >>> > Looking to carve out IT costs? >>> > www.redhat.com/carveoutcosts/ >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > Freeipa-users mailing list >>> > Freeipa-users at redhat.com >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >>> >>> >>> -- >>> Simo Sorce * Red Hat, Inc * New York >>> >>> >> >_______________________________________________ >Freeipa-users mailing list >Freeipa-users at redhat.com >https://www.redhat.com/mailman/listinfo/freeipa-users -- / Alexander Bokovoy From simo at redhat.com Sat Oct 6 18:45:25 2012 From: simo at redhat.com (Simo Sorce) Date: Sat, 06 Oct 2012 14:45:25 -0400 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> Message-ID: <1349549125.26127.108.camel@willson.li.ssimo.org> On Sat, 2012-10-06 at 08:12 +0200, Fred van Zwieten wrote: > Hang on..I don't see how this can work (I haven't tried it btw). > > > If I simply copy login to openvpn1 and call openvpn_auth_pam with that > file as a parameter, how can it magically know to query IPA for the > openvpn1 service as opposed to username/password? Must I not change > the openvpn1 file to have it check for the service? This is how it normally works with PAM enabled applications. Openvpn opens the PAM stack and tells it that 'openvpn1' is the name of the service performing an auth request. The PAM stack then opens the openvpn1 file to find what is the sepcific service configuration. The service name is passed in to all pam modules. In the PAM 'account' stack (which is run after the auth stack where the normal username/password can be used), the PAM framework will call pam_sss to check the account validity. This is where the pam_sss service will contact the sssd_pam daemon and tell it that service openvpn1 is trying to auth userX. The sssd_pam module checks the HBAC rules and tries to match user,machine,service to a rule. The rules will determine if the account is allowed on the machine for the specific service. If not pam_sss will return a suitable error in the account phase and openvpn should return an authentication error. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From fvzwieten at vxcompany.com Sat Oct 6 20:13:10 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Sat, 6 Oct 2012 22:13:10 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: <20121006183107.GZ17454@redhat.com> References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> <20121006183107.GZ17454@redhat.com> Message-ID: Alexander, Simo, Thank you very much for this extensive explanation. I'll set it up monday and let you know how it will go. Fred On Sat, Oct 6, 2012 at 8:31 PM, Alexander Bokovoy wrote: > On Sat, 06 Oct 2012, Fred van Zwieten wrote: > >Hang on..I don't see how this can work (I haven't tried it btw). > > > >If I simply copy login to openvpn1 and call openvpn_auth_pam with that > file > >as a parameter, how can it magically know to query IPA for the openvpn1 > >service as opposed to username/password? Must I not change the openvpn1 > >file to have it check for the service? > PAM defines a 'service', equal to the name of /etc/pam.d/ file. > An application using PAM starts using PAM functions by defining what > service it will be, then PAM code load definitions of the service from > the /etc/pam.d/ file and process them accordingly and apply > them in appropriate stages (authentication, account management, session > management, password checks). > > If your IPA hosts use SSSD daemon (default), then your PAM stack by > default is configured to authenticate against IPA server and use of its > features like Host-based access control (HBAC). You can verify it by > checking /etc/pam.d/system-auth (login PAM service includes this file). > > Let's say, you want to define PAM services 'ovpn_group1' and 'ovpn_group2' > that actually use login PAM service. You can do it following way: > > cd /etc/pam.d > ln -s login ovpn_group1 > ln -s login ovpn_group2 > > Now you have two configuration files named 'ovpn_group1' and > 'ovpn_group2', you need to allow their use in both OpenVPN and in IPA to > limit who can get into use of the service. > > On OpenVPN side you'd have two configuration files and set > plugin openvpn-auth-pam.so ovpn_group1 > in the first configuration file and > plugin openvpn-auth-pam.so ovpn_group2 > in the second. > > You don't need to add 'check_group' as the check would be done > automatically by pam_sss module using HBAC rules from IPA. > > In IPA you can define HBAC services corresponding to those > files. We have predefined some of them, for commonly available on the > machines, but you can expand that list. Go to 'Policy -> Host Base Acces > Control -> HBAC Services' and add two services there, 'ovpn_group1' and > 'ovpn_group2'. > > Next, define HBAC rules that reference the services ovpn_group1 > and ovpn_group2. Put appropriate groups in the rules as to what users > would be allowed to access them (and on which hosts). > > You need to be aware that IPA HBAC rules are explicit. If there is no > rule that allows access, it is denied. By default there is one rule > called 'allow_all' which is enabled, so access is allowed from any user > to any service on any host. Once you start using explicit HBAC rules, > you'll need to define all of them and then disable 'allow_all' rule > because otherwise it will always match and grant access. > > Here is how this difference is visible. I defined one PAM service, > 'test-service' by doing a symlink to login service file and used a > simple program > https://github.com/beatgammit/simple-pam/blob/master/src/test.c > to test. The program simply initializes PAM stack for specified service > ('check_user' in the source above, I only replaced that by > 'test-service' in my copy) and then runs a sequence of calls, like any > PAM-enabled application should do (except handling password expiration, > but that is detail here). > > I have defined special HBAC rule in IPA that only allowed users from a > group 'test' > to use service 'test-service'. User admin does not belong to that group, > user ab does belong to it. > > First with 'allow_all' rule enabled by default: > -sh-4.2$ ./app admin > Credentials accepted. > Password: > Account is valid. > Authenticated > -sh-4.2$ ./app ab > Credentials accepted. > Password: > Account is valid. > Authenticated > -sh-4.2$ > > Now I disabled 'allow_all' rule in the IPA web UI: > $ ./app admin > Credentials accepted. > Password: > Account is valid. > Not Authenticated > -sh-4.2$ ./app ab > Credentials accepted. > Password: > Account is valid. > Authenticated > -sh-4.2$ > > You'll see following in the /var/log/secure when 'allow_all' is > disabled: > ... > Oct 6 21:16:06 head app: pam_sss(test-service:auth): authentication > success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= > user=admin > Oct 6 21:16:06 head app: pam_sss(test-service:account): Access denied > for user admin: 6 (Permission denied) > ... > Oct 6 21:17:43 head app: pam_unix(test-service:auth): authentication > failure; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= > user=ab > Oct 6 21:17:46 head app: pam_sss(test-service:auth): authentication > success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= > user=ab > > Authentication went successfully (admin credentials were accepted) but then > account management part of pam_sss applied HBAC rules and found out that > none of the rules was matched, the access was denied. > > That's it, start your OpenVPN instances and they should be able to > log-in only those users who pass HBAC rules for their specific PAM > services. > > > >Fred > > > >> > >> > >> On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce wrote: > >> > >>> > >>> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 and > >>> openvn2 > >>> > >>> Then configure the two instance instance with: > >>> plugin openvpn_auth_pam openvpn1 > >>> and > >>> plugin openvpn_auth_pam openvpn2 > >>> respectively. > >>> > >>> Then you can create HBAC rules in IPA using openvpn1 and openvon2 as > >>> service names. > >>> > >>> Simo. > >>> > >>> On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: > >>> > Dmitri, > >>> > > >>> > > >>> > Well, this is, sort of, the point. I have no experience using pam, so > >>> > I have no idea how to set this up. > >>> > > >>> > > >>> > I have authentication up and running, but, like I said, both OpenVPN > >>> > instances happily authenticate users from both groups of users. > >>> > > >>> > > >>> > In my openvpn config file i have: > >>> > > >>> > > >>> > plugin openvpn_auth_pam login > >>> > > >>> > > >>> > where login is the /etc/pam.d/login file. I have not adjusted this > >>> > file. This is standard file for IPA client. > >>> > > >>> > > >>> > So, my idea was to do this in openvpn config file: > >>> > > >>> > > >>> > plugin openvpn_auth_pam login (can the user authenticate y/n?) > >>> > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is > >>> > the user member op OPENVPN1 y/n?) > >>> > > >>> > > >>> > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to > >>> > authenticate against IPA. I am not sure how this could be setup to > >>> > work with HBAC.. > >>> > > >>> > > >>> > Fred > >>> > > >>> > > >>> > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: > >>> > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: > >>> > > You are completely right :-) > >>> > > > >>> > > > >>> > > Both IPA server and client are RHEL6.3 x86_64 boxes. > >>> > > > >>> > > > >>> > > On the OpenVPN server (which is an IPA client), I have 2 > >>> > > OpenVPN instances running, because different users must end > >>> > > up in different subnet's > >>> > > > >>> > > > >>> > > OpenVPN instance 1 listens on port 50000 > >>> > > OpenVPN instance 2 listens on port 50001 > >>> > > > >>> > > > >>> > > Users for subnet 1 must connect and authenticate on > instance > >>> > > 1 (and get an IP in subnet 1) > >>> > > Users for subnet 2 must connect and authenticate on > instance > >>> > > 2 (and get an IP in subnet 2) > >>> > > > >>> > > > >>> > > Both OpenVPN instances use the login pam module. > >>> > > > >>> > > > >>> > > In this setup I can not prevent users for subnet 2 to > >>> > > connect and authenticate successfully on OpenVPN instance > 1. > >>> > > > >>> > > > >>> > > So, I would like to put the users for OpenVPN instance 1 in > >>> > > group OpenVPN1 en users for OpenVPN instance 2 in group > >>> > > OpenVPN2 on IPA. > >>> > > > >>> > > > >>> > > Next, the OpenVPN daemon must be able to check a user for > >>> > > membership. Is it is not a member, false is returned, and > >>> > > the OpenVMN authentication fails. > >>> > > > >>> > > > >>> > > Documentation for the openvpn_auth_pam is here. > >>> > > > >>> > > > >>> > > >>> > > >>> > OK, makes sense. > >>> > How does you pam configuration look like? > >>> > Especially the accounting part? What modules do you have > >>> > there? > >>> > Can it be PAM module you are using expecting some value that > >>> > need to be configured in openvpn_auth_pam config? > >>> > > >>> > > Fred > >>> > > > >>> > > > >>> > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal < > dpal at redhat.com> > >>> > > wrote: > >>> > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: > >>> > > > Hello, > >>> > > > > >>> > > > > >>> > > > I have a IPA server running. This server has > users > >>> > > > who are member to various groups. I want to query > >>> > > > the IPA server from an IPA client to know whether > >>> > > > a user is a member to a group. > >>> > > > > >>> > > > > >>> > > > I want to do this from the OpenVPN service using > >>> > > > the openvpn_auth_pam.so. Normally one uses this > >>> > > > like this: > >>> > > > > >>> > > > > >>> > > > openvpn_auth_pam.so login > >>> > > > > >>> > > > > >>> > > > This queries the PAM login (and thus IPA) is the > >>> > > > username/password from openvpn is valid. the > >>> > > > "login" is /etc/pam.d/login. OpenVPN docs say you > >>> > > > could use other modules instead of login. > >>> > > > > >>> > > > > >>> > > > So, I would like to add the next line: > >>> > > > > >>> > > > > >>> > > > openvpn_auth_pam.so group "openvpn" > >>> > > > > >>> > > > > >>> > > > Where a /etc/pam.d/group file would check whether > >>> > > > the user is member of the group "openvpn". If > not, > >>> > > > false is returned and the login attempt (thru > >>> > > > openvpn) fails. > >>> > > > > >>> > > > > >>> > > > Is this possible? If not is there a better way? > >>> > > > > >>> > > > > >>> > > > Fred > >>> > > > >>> > > > >>> > > > >>> > > Can you step up from the implementation and explain > >>> > > what you want to accomplish? > >>> > > It seems that you want to use OpenVPN and do some > >>> > > access control checks when user connects to > OpenVPN. > >>> > > Right? > >>> > > If you can describe the flow of operations we might > >>> > > be able guide you to the right solution. > >>> > > > >>> > > Also would be nice to understand what OS OpenVPN is > >>> > > running on. > >>> > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > > >>> > > > _______________________________________________ > >>> > > > Freeipa-users mailing list > >>> > > > Freeipa-users at redhat.com > >>> > > > > >>> https://www.redhat.com/mailman/listinfo/freeipa-users > >>> > > > >>> > > > >>> > > -- > >>> > > Thank you, > >>> > > Dmitri Pal > >>> > > > >>> > > Sr. Engineering Manager for IdM portfolio > >>> > > Red Hat Inc. > >>> > > > >>> > > > >>> > > ------------------------------- > >>> > > Looking to carve out IT costs? > >>> > > www.redhat.com/carveoutcosts/ > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > > >>> > > _______________________________________________ > >>> > > Freeipa-users mailing list > >>> > > Freeipa-users at redhat.com > >>> > > https://www.redhat.com/mailman/listinfo/freeipa-users > >>> > > >>> > > >>> > -- > >>> > Thank you, > >>> > Dmitri Pal > >>> > > >>> > Sr. Engineering Manager for IdM portfolio > >>> > Red Hat Inc. > >>> > > >>> > > >>> > ------------------------------- > >>> > Looking to carve out IT costs? > >>> > www.redhat.com/carveoutcosts/ > >>> > > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > Freeipa-users mailing list > >>> > Freeipa-users at redhat.com > >>> > https://www.redhat.com/mailman/listinfo/freeipa-users > >>> > >>> > >>> -- > >>> Simo Sorce * Red Hat, Inc * New York > >>> > >>> > >> > > >_______________________________________________ > >Freeipa-users mailing list > >Freeipa-users at redhat.com > >https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.williams at thehelpfulcat.com Mon Oct 8 12:05:03 2012 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Mon, 8 Oct 2012 13:05:03 +0100 Subject: [Freeipa-users] mod_nss issue. Message-ID: I have found a problem with mod_nss that appears to have been reported in 2010, but I cannot find any further reference to it. The 2010 reference contains a comment saying that it is an issue and needs to be fixed. I have not been able to find any issue tracking system for mod_nss and so haven't been able to check on the status. The problem is that mod_nss does not appear to respond with the correct certificate when multiple name virtual servers are configured on an instance of Apache. It always responds with the certificate of the first name virtual server defined. It does process the other sites' configurations because it complains if certificates with the aliases used are not in the database. This would not be an issue (for me) if mod_ssl could be used for virtual servers other than the IPA server, but they cannot co-exist. If you try to mix them, mod_ssl complains that port 443 is being used for the IPA server, but it is not SSL aware. I suppose it would be possible to reconfigure the IPA name virtual server to use mod_ssl bu exporting the certificate, but I really don't like to muck around with the directory server configuration more than is necessary as it is vital that it remains stable and secure. Could anyone enlighten me as to whether this issue is being looked at or even if it is fixed and the CentOS people (CentOS 6.3 standard repositories all packages up to date as of yesterday) just aren't supplying a new enough version of mod_nss. At the moment, I can use my SSL secured sites as the encryption works okay, but I cannot open them up as they report the wrong host name in the certificate. Regards Simon Williams -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Oct 8 12:30:01 2012 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 8 Oct 2012 15:30:01 +0300 Subject: [Freeipa-users] mod_nss issue. In-Reply-To: References: Message-ID: <20121008123001.GC17454@redhat.com> On Mon, 08 Oct 2012, Simon Williams wrote: >I have found a problem with mod_nss that appears to have been reported in >2010, but I cannot find any further reference to it. The 2010 reference >contains a comment saying that it is an issue and needs to be fixed. I >have not been able to find any issue tracking system for mod_nss and so >haven't been able to check on the status. > >The problem is that mod_nss does not appear to respond with the correct >certificate when multiple name virtual servers are configured on an >instance of Apache. It always responds with the certificate of the first >name virtual server defined. It does process the other sites' >configurations because it complains if certificates with the aliases used >are not in the database. This would not be an issue (for me) if mod_ssl >could be used for virtual servers other than the IPA server, but they >cannot co-exist. If you try to mix them, mod_ssl complains that port 443 >is being used for the IPA server, but it is not SSL aware. I suppose it >would be possible to reconfigure the IPA name virtual server to use mod_ssl >bu exporting the certificate, but I really don't like to muck around with >the directory server configuration more than is necessary as it is vital >that it remains stable and secure. > >Could anyone enlighten me as to whether this issue is being looked at or >even if it is fixed and the CentOS people (CentOS 6.3 standard repositories >all packages up to date as of yesterday) just aren't supplying a new enough >version of mod_nss. At the moment, I can use my SSL secured sites as the >encryption works okay, but I cannot open them up as they report the wrong >host name in the certificate. I assume all this comes because you run these virtual servers on the same instance as FreeIPA master itself, thus conflicting mod_ssl and mod_nss. Here is description how to make name-based SSL virtual hosts working in FreeIPA environment using mod_ssl. This howto assumes you are using a separate server than FreeIPA master to provide actual hosting for the virtual hosts which also makes sense because one would need to apply greater security protection to the KDC which runs on the same FreeIPA host. http://freeipa.org/page/Apache_SNI_With_Kerberos -- / Alexander Bokovoy From rcritten at redhat.com Mon Oct 8 12:45:20 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 08 Oct 2012 08:45:20 -0400 Subject: [Freeipa-users] mod_nss issue. In-Reply-To: <20121008123001.GC17454@redhat.com> References: <20121008123001.GC17454@redhat.com> Message-ID: <5072CAE0.8010102@redhat.com> Alexander Bokovoy wrote: > On Mon, 08 Oct 2012, Simon Williams wrote: >> I have found a problem with mod_nss that appears to have been reported in >> 2010, but I cannot find any further reference to it. The 2010 reference >> contains a comment saying that it is an issue and needs to be fixed. I >> have not been able to find any issue tracking system for mod_nss and so >> haven't been able to check on the status. >> >> The problem is that mod_nss does not appear to respond with the correct >> certificate when multiple name virtual servers are configured on an >> instance of Apache. It always responds with the certificate of the first >> name virtual server defined. It does process the other sites' >> configurations because it complains if certificates with the aliases used >> are not in the database. This would not be an issue (for me) if mod_ssl >> could be used for virtual servers other than the IPA server, but they >> cannot co-exist. If you try to mix them, mod_ssl complains that port 443 >> is being used for the IPA server, but it is not SSL aware. I suppose it >> would be possible to reconfigure the IPA name virtual server to use >> mod_ssl >> bu exporting the certificate, but I really don't like to muck around with >> the directory server configuration more than is necessary as it is vital >> that it remains stable and secure. >> >> Could anyone enlighten me as to whether this issue is being looked at or >> even if it is fixed and the CentOS people (CentOS 6.3 standard >> repositories >> all packages up to date as of yesterday) just aren't supplying a new >> enough >> version of mod_nss. At the moment, I can use my SSL secured sites as the >> encryption works okay, but I cannot open them up as they report the wrong >> host name in the certificate. > I assume all this comes because you run these virtual servers on the > same instance as FreeIPA master itself, thus conflicting mod_ssl and > mod_nss. > > Here is description how to make name-based SSL virtual hosts working in > FreeIPA environment using mod_ssl. This howto assumes you are using a > separate server than FreeIPA master to provide actual hosting for > the virtual hosts which also makes sense because one would need to apply > greater security protection to the KDC which runs on the same FreeIPA > host. > > http://freeipa.org/page/Apache_SNI_With_Kerberos > > mod_nss doesn't support SNI because NSS doesn't support SNI server-side yet (https://bugzilla.mozilla.org/show_bug.cgi?id=360421). The mod_nss bug tracker is bugzilla.redhat.com. mod_ssl and mod_nss can co-exist but not on the same port (which is true of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA server though, because mod_proxy only provides a single SSL interface and mod_ssl always registers it, locking mod_nss out. This is being worked on in mod_proxy. Switching to mod_ssl wouldn't require any changes to the directory server. rob From fvzwieten at vxcompany.com Mon Oct 8 13:07:29 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 8 Oct 2012 15:07:29 +0200 Subject: [Freeipa-users] Query IPA for group membership In-Reply-To: References: <506F1DFD.8050602@redhat.com> <506F25BC.5050104@redhat.com> <1349464155.26127.36.camel@willson.li.ssimo.org> <20121006183107.GZ17454@redhat.com> Message-ID: Guys, I have set it up, and it works like a charm! It blocked me out of RHN Satellite, because I had to disable the allow_all rule, but after setting IPA up with an rhn-satellite service HBAC that was also solved. Again, thank you for you're help! Fred On Sat, Oct 6, 2012 at 10:13 PM, Fred van Zwieten wrote: > Alexander, Simo, > > Thank you very much for this extensive explanation. I'll set it up monday > and let you know how it will go. > > Fred > > > On Sat, Oct 6, 2012 at 8:31 PM, Alexander Bokovoy wrote: > >> On Sat, 06 Oct 2012, Fred van Zwieten wrote: >> >Hang on..I don't see how this can work (I haven't tried it btw). >> > >> >If I simply copy login to openvpn1 and call openvpn_auth_pam with that >> file >> >as a parameter, how can it magically know to query IPA for the openvpn1 >> >service as opposed to username/password? Must I not change the openvpn1 >> >file to have it check for the service? >> PAM defines a 'service', equal to the name of /etc/pam.d/ file. >> An application using PAM starts using PAM functions by defining what >> service it will be, then PAM code load definitions of the service from >> the /etc/pam.d/ file and process them accordingly and apply >> them in appropriate stages (authentication, account management, session >> management, password checks). >> >> If your IPA hosts use SSSD daemon (default), then your PAM stack by >> default is configured to authenticate against IPA server and use of its >> features like Host-based access control (HBAC). You can verify it by >> checking /etc/pam.d/system-auth (login PAM service includes this file). >> >> Let's say, you want to define PAM services 'ovpn_group1' and 'ovpn_group2' >> that actually use login PAM service. You can do it following way: >> >> cd /etc/pam.d >> ln -s login ovpn_group1 >> ln -s login ovpn_group2 >> >> Now you have two configuration files named 'ovpn_group1' and >> 'ovpn_group2', you need to allow their use in both OpenVPN and in IPA to >> limit who can get into use of the service. >> >> On OpenVPN side you'd have two configuration files and set >> plugin openvpn-auth-pam.so ovpn_group1 >> in the first configuration file and >> plugin openvpn-auth-pam.so ovpn_group2 >> in the second. >> >> You don't need to add 'check_group' as the check would be done >> automatically by pam_sss module using HBAC rules from IPA. >> >> In IPA you can define HBAC services corresponding to those >> files. We have predefined some of them, for commonly available on the >> machines, but you can expand that list. Go to 'Policy -> Host Base Acces >> Control -> HBAC Services' and add two services there, 'ovpn_group1' and >> 'ovpn_group2'. >> >> Next, define HBAC rules that reference the services ovpn_group1 >> and ovpn_group2. Put appropriate groups in the rules as to what users >> would be allowed to access them (and on which hosts). >> >> You need to be aware that IPA HBAC rules are explicit. If there is no >> rule that allows access, it is denied. By default there is one rule >> called 'allow_all' which is enabled, so access is allowed from any user >> to any service on any host. Once you start using explicit HBAC rules, >> you'll need to define all of them and then disable 'allow_all' rule >> because otherwise it will always match and grant access. >> >> Here is how this difference is visible. I defined one PAM service, >> 'test-service' by doing a symlink to login service file and used a >> simple program >> https://github.com/beatgammit/simple-pam/blob/master/src/test.c >> to test. The program simply initializes PAM stack for specified service >> ('check_user' in the source above, I only replaced that by >> 'test-service' in my copy) and then runs a sequence of calls, like any >> PAM-enabled application should do (except handling password expiration, >> but that is detail here). >> >> I have defined special HBAC rule in IPA that only allowed users from a >> group 'test' >> to use service 'test-service'. User admin does not belong to that group, >> user ab does belong to it. >> >> First with 'allow_all' rule enabled by default: >> -sh-4.2$ ./app admin >> Credentials accepted. >> Password: >> Account is valid. >> Authenticated >> -sh-4.2$ ./app ab >> Credentials accepted. >> Password: >> Account is valid. >> Authenticated >> -sh-4.2$ >> >> Now I disabled 'allow_all' rule in the IPA web UI: >> $ ./app admin >> Credentials accepted. >> Password: >> Account is valid. >> Not Authenticated >> -sh-4.2$ ./app ab >> Credentials accepted. >> Password: >> Account is valid. >> Authenticated >> -sh-4.2$ >> >> You'll see following in the /var/log/secure when 'allow_all' is >> disabled: >> ... >> Oct 6 21:16:06 head app: pam_sss(test-service:auth): authentication >> success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= >> user=admin >> Oct 6 21:16:06 head app: pam_sss(test-service:account): Access denied >> for user admin: 6 (Permission denied) >> ... >> Oct 6 21:17:43 head app: pam_unix(test-service:auth): authentication >> failure; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= >> user=ab >> Oct 6 21:17:46 head app: pam_sss(test-service:auth): authentication >> success; logname=ab uid=1471000004 euid=1471000004 tty= ruser= rhost= >> user=ab >> >> Authentication went successfully (admin credentials were accepted) but >> then >> account management part of pam_sss applied HBAC rules and found out that >> none of the rules was matched, the access was denied. >> >> That's it, start your OpenVPN instances and they should be able to >> log-in only those users who pass HBAC rules for their specific PAM >> services. >> >> >> >Fred >> > >> >> >> >> >> >> On Fri, Oct 5, 2012 at 9:09 PM, Simo Sorce wrote: >> >> >> >>> >> >>> Fred I suggest you copy the 'login' file into 2 new files: openvpn1 >> and >> >>> openvn2 >> >>> >> >>> Then configure the two instance instance with: >> >>> plugin openvpn_auth_pam openvpn1 >> >>> and >> >>> plugin openvpn_auth_pam openvpn2 >> >>> respectively. >> >>> >> >>> Then you can create HBAC rules in IPA using openvpn1 and openvon2 as >> >>> service names. >> >>> >> >>> Simo. >> >>> >> >>> On Fri, 2012-10-05 at 20:58 +0200, Fred van Zwieten wrote: >> >>> > Dmitri, >> >>> > >> >>> > >> >>> > Well, this is, sort of, the point. I have no experience using pam, >> so >> >>> > I have no idea how to set this up. >> >>> > >> >>> > >> >>> > I have authentication up and running, but, like I said, both OpenVPN >> >>> > instances happily authenticate users from both groups of users. >> >>> > >> >>> > >> >>> > In my openvpn config file i have: >> >>> > >> >>> > >> >>> > plugin openvpn_auth_pam login >> >>> > >> >>> > >> >>> > where login is the /etc/pam.d/login file. I have not adjusted this >> >>> > file. This is standard file for IPA client. >> >>> > >> >>> > >> >>> > So, my idea was to do this in openvpn config file: >> >>> > >> >>> > >> >>> > plugin openvpn_auth_pam login (can the user authenticate y/n?) >> >>> > plugin openvpn_auth_pam check_group name USERNAME group OPENVPN1 (is >> >>> > the user member op OPENVPN1 y/n?) >> >>> > >> >>> > >> >>> > plugin openvpn_auth_pam is afaik the only way to get OpenVPN to >> >>> > authenticate against IPA. I am not sure how this could be setup to >> >>> > work with HBAC.. >> >>> > >> >>> > >> >>> > Fred >> >>> > >> >>> > >> >>> > On Fri, Oct 5, 2012 at 8:23 PM, Dmitri Pal wrote: >> >>> > On 10/05/2012 02:13 PM, Fred van Zwieten wrote: >> >>> > > You are completely right :-) >> >>> > > >> >>> > > >> >>> > > Both IPA server and client are RHEL6.3 x86_64 boxes. >> >>> > > >> >>> > > >> >>> > > On the OpenVPN server (which is an IPA client), I have 2 >> >>> > > OpenVPN instances running, because different users must >> end >> >>> > > up in different subnet's >> >>> > > >> >>> > > >> >>> > > OpenVPN instance 1 listens on port 50000 >> >>> > > OpenVPN instance 2 listens on port 50001 >> >>> > > >> >>> > > >> >>> > > Users for subnet 1 must connect and authenticate on >> instance >> >>> > > 1 (and get an IP in subnet 1) >> >>> > > Users for subnet 2 must connect and authenticate on >> instance >> >>> > > 2 (and get an IP in subnet 2) >> >>> > > >> >>> > > >> >>> > > Both OpenVPN instances use the login pam module. >> >>> > > >> >>> > > >> >>> > > In this setup I can not prevent users for subnet 2 to >> >>> > > connect and authenticate successfully on OpenVPN instance >> 1. >> >>> > > >> >>> > > >> >>> > > So, I would like to put the users for OpenVPN instance 1 >> in >> >>> > > group OpenVPN1 en users for OpenVPN instance 2 in group >> >>> > > OpenVPN2 on IPA. >> >>> > > >> >>> > > >> >>> > > Next, the OpenVPN daemon must be able to check a user for >> >>> > > membership. Is it is not a member, false is returned, and >> >>> > > the OpenVMN authentication fails. >> >>> > > >> >>> > > >> >>> > > Documentation for the openvpn_auth_pam is here. >> >>> > > >> >>> > > >> >>> > >> >>> > >> >>> > OK, makes sense. >> >>> > How does you pam configuration look like? >> >>> > Especially the accounting part? What modules do you have >> >>> > there? >> >>> > Can it be PAM module you are using expecting some value that >> >>> > need to be configured in openvpn_auth_pam config? >> >>> > >> >>> > > Fred >> >>> > > >> >>> > > >> >>> > > On Fri, Oct 5, 2012 at 7:50 PM, Dmitri Pal < >> dpal at redhat.com> >> >>> > > wrote: >> >>> > > On 10/05/2012 01:36 PM, Fred van Zwieten wrote: >> >>> > > > Hello, >> >>> > > > >> >>> > > > >> >>> > > > I have a IPA server running. This server has >> users >> >>> > > > who are member to various groups. I want to >> query >> >>> > > > the IPA server from an IPA client to know >> whether >> >>> > > > a user is a member to a group. >> >>> > > > >> >>> > > > >> >>> > > > I want to do this from the OpenVPN service using >> >>> > > > the openvpn_auth_pam.so. Normally one uses this >> >>> > > > like this: >> >>> > > > >> >>> > > > >> >>> > > > openvpn_auth_pam.so login >> >>> > > > >> >>> > > > >> >>> > > > This queries the PAM login (and thus IPA) is the >> >>> > > > username/password from openvpn is valid. the >> >>> > > > "login" is /etc/pam.d/login. OpenVPN docs say >> you >> >>> > > > could use other modules instead of login. >> >>> > > > >> >>> > > > >> >>> > > > So, I would like to add the next line: >> >>> > > > >> >>> > > > >> >>> > > > openvpn_auth_pam.so group "openvpn" >> >>> > > > >> >>> > > > >> >>> > > > Where a /etc/pam.d/group file would check >> whether >> >>> > > > the user is member of the group "openvpn". If >> not, >> >>> > > > false is returned and the login attempt (thru >> >>> > > > openvpn) fails. >> >>> > > > >> >>> > > > >> >>> > > > Is this possible? If not is there a better way? >> >>> > > > >> >>> > > > >> >>> > > > Fred >> >>> > > >> >>> > > >> >>> > > >> >>> > > Can you step up from the implementation and >> explain >> >>> > > what you want to accomplish? >> >>> > > It seems that you want to use OpenVPN and do some >> >>> > > access control checks when user connects to >> OpenVPN. >> >>> > > Right? >> >>> > > If you can describe the flow of operations we >> might >> >>> > > be able guide you to the right solution. >> >>> > > >> >>> > > Also would be nice to understand what OS OpenVPN >> is >> >>> > > running on. >> >>> > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > >> >>> > > > _______________________________________________ >> >>> > > > Freeipa-users mailing list >> >>> > > > Freeipa-users at redhat.com >> >>> > > > >> >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> >>> > > >> >>> > > >> >>> > > -- >> >>> > > Thank you, >> >>> > > Dmitri Pal >> >>> > > >> >>> > > Sr. Engineering Manager for IdM portfolio >> >>> > > Red Hat Inc. >> >>> > > >> >>> > > >> >>> > > ------------------------------- >> >>> > > Looking to carve out IT costs? >> >>> > > www.redhat.com/carveoutcosts/ >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > >> >>> > > _______________________________________________ >> >>> > > Freeipa-users mailing list >> >>> > > Freeipa-users at redhat.com >> >>> > > https://www.redhat.com/mailman/listinfo/freeipa-users >> >>> > >> >>> > >> >>> > -- >> >>> > Thank you, >> >>> > Dmitri Pal >> >>> > >> >>> > Sr. Engineering Manager for IdM portfolio >> >>> > Red Hat Inc. >> >>> > >> >>> > >> >>> > ------------------------------- >> >>> > Looking to carve out IT costs? >> >>> > www.redhat.com/carveoutcosts/ >> >>> > >> >>> > >> >>> > >> >>> > >> >>> > _______________________________________________ >> >>> > Freeipa-users mailing list >> >>> > Freeipa-users at redhat.com >> >>> > https://www.redhat.com/mailman/listinfo/freeipa-users >> >>> >> >>> >> >>> -- >> >>> Simo Sorce * Red Hat, Inc * New York >> >>> >> >>> >> >> >> >> >_______________________________________________ >> >Freeipa-users mailing list >> >Freeipa-users at redhat.com >> >https://www.redhat.com/mailman/listinfo/freeipa-users >> >> >> >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.williams at thehelpfulcat.com Mon Oct 8 14:19:23 2012 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Mon, 8 Oct 2012 15:19:23 +0100 Subject: [Freeipa-users] mod_nss issue. In-Reply-To: <5072CAE0.8010102@redhat.com> References: <20121008123001.GC17454@redhat.com> <5072CAE0.8010102@redhat.com> Message-ID: I understand exactly where you are coming from Alexander and in an ideal world the web sites that I want to get at externally would be on a different server. I am not the normal type of FreeIPA user, being a very small business with only a couple of users and half a dozen or so machines and, currently, very limited resources. IPA makes it so easy to administer the network however that I would be loathed not to use it! We are developing software and I only have one server that I can dedicate to being a stable host. I have two other machines on the network that are currently always on and both are used for development both running Fedora, one x64 and one Arm. Neither of these machines could be considered stable. The other machines are a mix of Windows and Fedora laptops, soon to have a Mac added if my partner gets her way. I currently restrict access to the IPA name virtual server by not having a publicly accessible name for it (and using "deny all", "allow *local network*", but I don't think that does anything as the incoming packets are routed using NAT, but it costs nothing to have it there!). I realise that this is insecure as a request on port 443 that does not have a host name will be handled by the default and therefore IPA name virtual server. That is something I still have to address, but was intending to make the default name virtual server just redirect to a 404 error page. I had already found, read and tried the guide at the link you sent, that is how I discovered that mod_ssl and mod_nss wouldn't co-exist. Your comment Rob has started me thinking along different lines than I was. If the mod_ssl/mod_nss incompatibility only exists if the same port and IP address is used, since I specifically don't want the IPA server to be available outside the local network, I could either use a different port for the non-IPA name virtual servers (the gateway could still present 80 and 443 to the outside world since the gateway is redirecting the packets anyway). Or a different virtual IP address on the server for the non-IPA sites (only one NIC on the server and no free slots, so couldn't be physically separate). This would kill two birds with one stone (ie. make the IPA instance more secure and solve the certificate problem). It would also make it easier to put the non-IPA web servers on a different machine when I am in a position to do that. Thank you both for your help. I think that you have prodded me in the right direction for a workaround. Regards Simon Williams On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden wrote: > Alexander Bokovoy wrote: > >> On Mon, 08 Oct 2012, Simon Williams wrote: >> >>> I have found a problem with mod_nss that appears to have been reported in >>> 2010, but I cannot find any further reference to it. The 2010 reference >>> contains a comment saying that it is an issue and needs to be fixed. I >>> have not been able to find any issue tracking system for mod_nss and so >>> haven't been able to check on the status. >>> >>> The problem is that mod_nss does not appear to respond with the correct >>> certificate when multiple name virtual servers are configured on an >>> instance of Apache. It always responds with the certificate of the first >>> name virtual server defined. It does process the other sites' >>> configurations because it complains if certificates with the aliases used >>> are not in the database. This would not be an issue (for me) if mod_ssl >>> could be used for virtual servers other than the IPA server, but they >>> cannot co-exist. If you try to mix them, mod_ssl complains that port 443 >>> is being used for the IPA server, but it is not SSL aware. I suppose it >>> would be possible to reconfigure the IPA name virtual server to use >>> mod_ssl >>> bu exporting the certificate, but I really don't like to muck around with >>> the directory server configuration more than is necessary as it is vital >>> that it remains stable and secure. >>> >>> Could anyone enlighten me as to whether this issue is being looked at or >>> even if it is fixed and the CentOS people (CentOS 6.3 standard >>> repositories >>> all packages up to date as of yesterday) just aren't supplying a new >>> enough >>> version of mod_nss. At the moment, I can use my SSL secured sites as the >>> encryption works okay, but I cannot open them up as they report the wrong >>> host name in the certificate. >>> >> I assume all this comes because you run these virtual servers on the >> same instance as FreeIPA master itself, thus conflicting mod_ssl and >> mod_nss. >> >> Here is description how to make name-based SSL virtual hosts working in >> FreeIPA environment using mod_ssl. This howto assumes you are using a >> separate server than FreeIPA master to provide actual hosting for >> the virtual hosts which also makes sense because one would need to apply >> greater security protection to the KDC which runs on the same FreeIPA >> host. >> >> http://freeipa.org/page/**Apache_SNI_With_Kerberos >> >> >> > mod_nss doesn't support SNI because NSS doesn't support SNI server-side > yet (https://bugzilla.mozilla.org/**show_bug.cgi?id=360421 > ). > > The mod_nss bug tracker is bugzilla.redhat.com. > > mod_ssl and mod_nss can co-exist but not on the same port (which is true > of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA server > though, because mod_proxy only provides a single SSL interface and mod_ssl > always registers it, locking mod_nss out. This is being worked on in > mod_proxy. > > Switching to mod_ssl wouldn't require any changes to the directory server. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Oct 8 14:33:11 2012 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 08 Oct 2012 16:33:11 +0200 Subject: [Freeipa-users] mod_nss issue. In-Reply-To: References: <20121008123001.GC17454@redhat.com> <5072CAE0.8010102@redhat.com> Message-ID: <5072E427.6000900@redhat.com> Hello, Did you consider virtualization for host accessible from public networks? Performance degradation is usually small nowadays and you can save some headaches (and create different one :-)). Petr^2 Spacek On 10/08/2012 04:19 PM, Simon Williams wrote: > I understand exactly where you are coming from Alexander and in an ideal world > the web sites that I want to get at externally would be on a different server. > I am not the normal type of FreeIPA user, being a very small business with > only a couple of users and half a dozen or so machines and, currently, very > limited resources. IPA makes it so easy to administer the network however > that I would be loathed not to use it! We are developing software and I only > have one server that I can dedicate to being a stable host. I have two other > machines on the network that are currently always on and both are used for > development both running Fedora, one x64 and one Arm. Neither of these > machines could be considered stable. The other machines are a mix of Windows > and Fedora laptops, soon to have a Mac added if my partner gets her way. I > currently restrict access to the IPA name virtual server by not having a > publicly accessible name for it (and using "deny all", "allow /local > network/", but I don't think that does anything as the incoming packets are > routed using NAT, but it costs nothing to have it there!). I realise that > this is insecure as a request on port 443 that does not have a host name will > be handled by the default and therefore IPA name virtual server. That is > something I still have to address, but was intending to make the default name > virtual server just redirect to a 404 error page. > > I had already found, read and tried the guide at the link you sent, that is > how I discovered that mod_ssl and mod_nss wouldn't co-exist. > > Your comment Rob has started me thinking along different lines than I was. If > the mod_ssl/mod_nss incompatibility only exists if the same port and IP > address is used, since I specifically don't want the IPA server to be > available outside the local network, I could either use a different port for > the non-IPA name virtual servers (the gateway could still present 80 and 443 > to the outside world since the gateway is redirecting the packets anyway). Or > a different virtual IP address on the server for the non-IPA sites (only one > NIC on the server and no free slots, so couldn't be physically separate). > This would kill two birds with one stone (ie. make the IPA instance more > secure and solve the certificate problem). It would also make it easier to > put the non-IPA web servers on a different machine when I am in a position to > do that. > > Thank you both for your help. I think that you have prodded me in the right > direction for a workaround. > > Regards > > Simon Williams > > On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden > wrote: > > Alexander Bokovoy wrote: > > On Mon, 08 Oct 2012, Simon Williams wrote: > > I have found a problem with mod_nss that appears to have been > reported in > 2010, but I cannot find any further reference to it. The 2010 > reference > contains a comment saying that it is an issue and needs to be > fixed. I > have not been able to find any issue tracking system for mod_nss > and so > haven't been able to check on the status. > > The problem is that mod_nss does not appear to respond with the > correct > certificate when multiple name virtual servers are configured on an > instance of Apache. It always responds with the certificate of > the first > name virtual server defined. It does process the other sites' > configurations because it complains if certificates with the > aliases used > are not in the database. This would not be an issue (for me) if > mod_ssl > could be used for virtual servers other than the IPA server, but they > cannot co-exist. If you try to mix them, mod_ssl complains that > port 443 > is being used for the IPA server, but it is not SSL aware. I > suppose it > would be possible to reconfigure the IPA name virtual server to use > mod_ssl > bu exporting the certificate, but I really don't like to muck > around with > the directory server configuration more than is necessary as it is > vital > that it remains stable and secure. > > Could anyone enlighten me as to whether this issue is being looked > at or > even if it is fixed and the CentOS people (CentOS 6.3 standard > repositories > all packages up to date as of yesterday) just aren't supplying a new > enough > version of mod_nss. At the moment, I can use my SSL secured sites > as the > encryption works okay, but I cannot open them up as they report > the wrong > host name in the certificate. > > I assume all this comes because you run these virtual servers on the > same instance as FreeIPA master itself, thus conflicting mod_ssl and > mod_nss. > > Here is description how to make name-based SSL virtual hosts working in > FreeIPA environment using mod_ssl. This howto assumes you are using a > separate server than FreeIPA master to provide actual hosting for > the virtual hosts which also makes sense because one would need to apply > greater security protection to the KDC which runs on the same FreeIPA > host. > > http://freeipa.org/page/__Apache_SNI_With_Kerberos > > > > > mod_nss doesn't support SNI because NSS doesn't support SNI server-side > yet (https://bugzilla.mozilla.org/__show_bug.cgi?id=360421 > ). > > The mod_nss bug tracker is bugzilla.redhat.com . > > mod_ssl and mod_nss can co-exist but not on the same port (which is true > of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA server > though, because mod_proxy only provides a single SSL interface and mod_ssl > always registers it, locking mod_nss out. This is being worked on in > mod_proxy. > > Switching to mod_ssl wouldn't require any changes to the directory server. > > rob From simon.williams at thehelpfulcat.com Mon Oct 8 16:49:54 2012 From: simon.williams at thehelpfulcat.com (Simon Williams) Date: Mon, 8 Oct 2012 17:49:54 +0100 Subject: [Freeipa-users] mod_nss issue. In-Reply-To: <5072E427.6000900@redhat.com> References: <20121008123001.GC17454@redhat.com> <5072CAE0.8010102@redhat.com> <5072E427.6000900@redhat.com> Message-ID: I had considered virtualisation, but it's another learning curve to go through and until we have a product, all time spent getting the infrastructure in place is pushing back the product delivery. If we are successful then getting new servers won't be an issue. If we aren't it doesn't matter, except as an intellectual exercise. Ironically, if we are successful the problems go away anyway as I will no longer need to fit stuff around my day job and so won't need to access the systems the from the train, etc. and will be able to work on the local network most of the time! Regards Simon Williams On Oct 8, 2012 3:37 PM, "Petr Spacek" wrote: > Hello, > > Did you consider virtualization for host accessible from public networks? > > Performance degradation is usually small nowadays and you can save some > headaches (and create different one :-)). > > Petr^2 Spacek > > On 10/08/2012 04:19 PM, Simon Williams wrote: > >> I understand exactly where you are coming from Alexander and in an ideal >> world >> the web sites that I want to get at externally would be on a different >> server. >> I am not the normal type of FreeIPA user, being a very small business >> with >> only a couple of users and half a dozen or so machines and, currently, >> very >> limited resources. IPA makes it so easy to administer the network however >> that I would be loathed not to use it! We are developing software and I >> only >> have one server that I can dedicate to being a stable host. I have two >> other >> machines on the network that are currently always on and both are used for >> development both running Fedora, one x64 and one Arm. Neither of these >> machines could be considered stable. The other machines are a mix of >> Windows >> and Fedora laptops, soon to have a Mac added if my partner gets her way. >> I >> currently restrict access to the IPA name virtual server by not having a >> publicly accessible name for it (and using "deny all", "allow /local >> network/", but I don't think that does anything as the incoming packets >> are >> routed using NAT, but it costs nothing to have it there!). I realise that >> this is insecure as a request on port 443 that does not have a host name >> will >> be handled by the default and therefore IPA name virtual server. That is >> something I still have to address, but was intending to make the default >> name >> virtual server just redirect to a 404 error page. >> >> I had already found, read and tried the guide at the link you sent, that >> is >> how I discovered that mod_ssl and mod_nss wouldn't co-exist. >> >> Your comment Rob has started me thinking along different lines than I >> was. If >> the mod_ssl/mod_nss incompatibility only exists if the same port and IP >> address is used, since I specifically don't want the IPA server to be >> available outside the local network, I could either use a different port >> for >> the non-IPA name virtual servers (the gateway could still present 80 and >> 443 >> to the outside world since the gateway is redirecting the packets >> anyway). Or >> a different virtual IP address on the server for the non-IPA sites (only >> one >> NIC on the server and no free slots, so couldn't be physically separate). >> This would kill two birds with one stone (ie. make the IPA instance more >> secure and solve the certificate problem). It would also make it easier >> to >> put the non-IPA web servers on a different machine when I am in a >> position to >> do that. >> >> Thank you both for your help. I think that you have prodded me in the >> right >> direction for a workaround. >> >> Regards >> >> Simon Williams >> >> On Mon, Oct 8, 2012 at 1:45 PM, Rob Crittenden > > wrote: >> >> Alexander Bokovoy wrote: >> >> On Mon, 08 Oct 2012, Simon Williams wrote: >> >> I have found a problem with mod_nss that appears to have been >> reported in >> 2010, but I cannot find any further reference to it. The 2010 >> reference >> contains a comment saying that it is an issue and needs to be >> fixed. I >> have not been able to find any issue tracking system for >> mod_nss >> and so >> haven't been able to check on the status. >> >> The problem is that mod_nss does not appear to respond with >> the >> correct >> certificate when multiple name virtual servers are configured >> on an >> instance of Apache. It always responds with the certificate >> of >> the first >> name virtual server defined. It does process the other sites' >> configurations because it complains if certificates with the >> aliases used >> are not in the database. This would not be an issue (for me) >> if >> mod_ssl >> could be used for virtual servers other than the IPA server, >> but they >> cannot co-exist. If you try to mix them, mod_ssl complains >> that >> port 443 >> is being used for the IPA server, but it is not SSL aware. I >> suppose it >> would be possible to reconfigure the IPA name virtual server >> to use >> mod_ssl >> bu exporting the certificate, but I really don't like to muck >> around with >> the directory server configuration more than is necessary as >> it is >> vital >> that it remains stable and secure. >> >> Could anyone enlighten me as to whether this issue is being >> looked >> at or >> even if it is fixed and the CentOS people (CentOS 6.3 standard >> repositories >> all packages up to date as of yesterday) just aren't >> supplying a new >> enough >> version of mod_nss. At the moment, I can use my SSL secured >> sites >> as the >> encryption works okay, but I cannot open them up as they >> report >> the wrong >> host name in the certificate. >> >> I assume all this comes because you run these virtual servers on >> the >> same instance as FreeIPA master itself, thus conflicting mod_ssl >> and >> mod_nss. >> >> Here is description how to make name-based SSL virtual hosts >> working in >> FreeIPA environment using mod_ssl. This howto assumes you are >> using a >> separate server than FreeIPA master to provide actual hosting for >> the virtual hosts which also makes sense because one would need >> to apply >> greater security protection to the KDC which runs on the same >> FreeIPA >> host. >> >> http://freeipa.org/page/__**Apache_SNI_With_Kerberos >> >> > >> >> >> >> mod_nss doesn't support SNI because NSS doesn't support SNI >> server-side >> yet (https://bugzilla.mozilla.org/**__show_bug.cgi?id=360421 >> >> >). >> >> The mod_nss bug tracker is bugzilla.redhat.com < >> http://bugzilla.redhat.com>. >> >> mod_ssl and mod_nss can co-exist but not on the same port (which is >> true >> of any two servers). mod_ssl and mod_nss cannot co-exist on an IPA >> server >> though, because mod_proxy only provides a single SSL interface and >> mod_ssl >> always registers it, locking mod_nss out. This is being worked on in >> mod_proxy. >> >> Switching to mod_ssl wouldn't require any changes to the directory >> server. >> >> rob >> > > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Mon Oct 8 22:04:24 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 09 Oct 2012 00:04:24 +0200 Subject: [Freeipa-users] sudo questions Message-ID: <50734DE8.1090802@nixtra.com> Hi, I've been testing the sudo integration with IPA and I came across some questions: 1. When I disable or delete a sudo rule, it's not removed from the ou=sudoers until I restart the directory server. Am I doing something wrong? (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) 2. Perhaps the documentation should mention creating a rule called "defaults" to put default options for all sudo rules in. Or even better having one created by default with a fresh IPA installation. It took me a few seconds to figure out where to put default options for all sudo rules. 3. sudo integration with SSSD does not work when anonymous LDAP authentication is disabled at the server. Enabling verbose logging in SSSD seem to suggest that it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make sudo display these options as errors when sudo debugging is enabled (sudoers_debug 1 in /etc/ldap.conf or /etc/sudo-ldap.conf): sudo: unknown defaults entry `env_keep ' 5. It would be great to have a set of sudo commands and a set of sudo command groups installed by default. 6. Adding a sudo command having multiple commands listed (such as: "/sbin/route, /sbin/ifconfig, /bin/ping ") is allowed in IPA and does list it correctly as allowed commands when doing "sudo -l", however attempting to execute one of the commands in the list using sudo fails. I did my testing with IPA server 2.2 in CentOS 6.3. Regards, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Oct 8 22:59:39 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 8 Oct 2012 22:59:39 +0000 Subject: [Freeipa-users] confusing users Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, When a user logs in for the first time nad they have to set a new password, if it doesnt meet the passowrd standard/policy it fails with a "authentication token manipulation error" is it possible to get that changed so it says "password does not meet policy"? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 8 23:13:26 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 08 Oct 2012 19:13:26 -0400 Subject: [Freeipa-users] sudo questions In-Reply-To: <50734DE8.1090802@nixtra.com> References: <50734DE8.1090802@nixtra.com> Message-ID: <50735E16.5060404@redhat.com> On 10/08/2012 06:04 PM, Sigbjorn Lie wrote: > Hi, Thank you for the report! > > I've been testing the sudo integration with IPA and I came across some > questions: > > 1. When I disable or delete a sudo rule, it's not removed from the > ou=sudoers until I restart the directory server. Am I doing something > wrong? (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) > This might be a bug in the compat plugin. The internal tree is reflected into the standard sudo schema that is supposed to be kept in sync with the internal tree. However I would be surprised if there is actually a bug. > 2. Perhaps the documentation should mention creating a rule called > "defaults" to put default options for all sudo rules in. Or even > better having one created by default with a fresh IPA installation. It > took me a few seconds to figure out where to put default options for > all sudo rules. Can you please open an RFE in trac? https://fedorahosted.org/freeipa > > 3. sudo integration with SSSD does not work when anonymous LDAP > authentication is disabled at the server. Enabling verbose logging in > SSSD seem to suggest that it's attempting anonymous auth only. > (sssd-1.8.4-14.fc17.x86_64) Which integration you are trying? The one that was tech preview in 1.8? The one that makes SSSD cache sudo rules? It was significantly rewritten in 1.9. Can you please try with 1.9? > > 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make > sudo display these options as errors when sudo debugging is enabled > (sudoers_debug 1 in /etc/ldap.conf or /etc/sudo-ldap.conf): > sudo: unknown defaults entry `env_keep ' Yes. This is a known issue already filed as a ticket. > > 5. It would be great to have a set of sudo commands and a set of sudo > command groups installed by default. Can you make a proposal about what groups would you like to see in an RFE? https://fedorahosted.org/freeipa > > 6. Adding a sudo command having multiple commands listed (such as: > "/sbin/route, /sbin/ifconfig, /bin/ping > ") > is allowed in IPA and does list it correctly as allowed commands when > doing "sudo -l", however attempting to execute one of the commands in > the list using sudo fails. > Can you please try SSSD 1.9? > I did my testing with IPA server 2.2 in CentOS 6.3. > > > > Regards, > Siggi > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thildred at redhat.com Tue Oct 9 00:38:15 2012 From: thildred at redhat.com (Tim Hildred) Date: Mon, 8 Oct 2012 20:38:15 -0400 (EDT) Subject: [Freeipa-users] confusing users In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <713507778.9451168.1349743095805.JavaMail.root@redhat.com> > > When a user logs in for the first time nad they have to set a new > password, if it doesnt meet the passowrd standard/policy it fails > with a "authentication token manipulation error" is it possible to > get that changed so it says "password does not meet policy"? > +1 And additionally, some really clear documentation on how on: 1) what is an acceptable password under the default password policy and why, with examples. 2) how to alter the password policy to meet the needs of your environment, with examples. Tim Hildred, RHCE Content Author II - Engineering Content Services, Red Hat, Inc. Brisbane, Australia Email: thildred at redhat.com Internal: 8588287 Mobile: +61 4 666 25242 IRC: thildred From Steven.Jones at vuw.ac.nz Tue Oct 9 00:47:21 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 9 Oct 2012 00:47:21 +0000 Subject: [Freeipa-users] confusing users In-Reply-To: <713507778.9451168.1349743095805.JavaMail.root@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz>, <713507778.9451168.1349743095805.JavaMail.root@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E50B6@STAWINCOX10MBX1.staff.vuw.ac.nz> 1) I had to test as somehow I cant fathom what it means either!.... 2) That can be altered in the policy section, Ive altered mine to match my AD policy but with 6000+ users.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Tim Hildred [thildred at redhat.com] Sent: Tuesday, 9 October 2012 1:38 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] confusing users > > When a user logs in for the first time nad they have to set a new > password, if it doesnt meet the passowrd standard/policy it fails > with a "authentication token manipulation error" is it possible to > get that changed so it says "password does not meet policy"? > +1 And additionally, some really clear documentation on how on: 1) what is an acceptable password under the default password policy and why, with examples. 2) how to alter the password policy to meet the needs of your environment, with examples. Tim Hildred, RHCE Content Author II - Engineering Content Services, Red Hat, Inc. Brisbane, Australia Email: thildred at redhat.com Internal: 8588287 Mobile: +61 4 666 25242 IRC: thildred From jhrozek at redhat.com Tue Oct 9 05:59:58 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 9 Oct 2012 07:59:58 +0200 Subject: [Freeipa-users] sudo questions In-Reply-To: <50734DE8.1090802@nixtra.com> References: <50734DE8.1090802@nixtra.com> Message-ID: <20121009055958.GH685@hendrix.brq.redhat.com> On Tue, Oct 09, 2012 at 12:04:24AM +0200, Sigbjorn Lie wrote: > Hi, > Hi Siggi, > 3. sudo integration with SSSD does not work when anonymous LDAP > authentication is disabled at the server. Enabling verbose logging > in SSSD seem to suggest that it's attempting anonymous auth only. > (sssd-1.8.4-14.fc17.x86_64) This is a known limitation of both 1.8 and 1.9. SSSD-1.9 documentation includes an example on how to configure the sudo provider against an IPA server: http://jhrozek.fedorapeople.org/sssd/1.9.1/man/sssd-sudo.5.html We're tracking creating a native IPA sudo backend in SSSD-1.10: https://fedorahosted.org/sssd/ticket/1108 > 6. Adding a sudo command having multiple commands listed (such as: > "/sbin/route, /sbin/ifconfig, /bin/ping ") > is allowed in IPA and does list it correctly as allowed commands > when doing "sudo -l", however attempting to execute one of the > commands in the list using sudo fails. This was with SSSD or nss-pam-ldapd? From mkosek at redhat.com Tue Oct 9 06:54:11 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 09 Oct 2012 08:54:11 +0200 Subject: [Freeipa-users] confusing users In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5073CA13.8040205@redhat.com> On 10/09/2012 12:59 AM, Steven Jones wrote: > Hi, > > When a user logs in for the first time nad they have to set a new password, if > it doesnt meet the passowrd standard/policy it fails with a "authentication > token manipulation error" is it possible to get that changed so it says > "password does not meet policy"? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > Hello Steven, what service did you use to log in (package versions may help too)? When I tried ssh-ing a new user or login via login terminal, I got an explaining error message: 1) PAM prevented the change # ssh fbar at ipa.example.com fbar at ipa.example.com's password: Password expired. Change your password now. Last login: Tue Oct 9 02:44:19 2012 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: BAD PASSWORD: The password is shorter than 8 characters New password: BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word New password: Retype new password: Connection to ipa.example.com closed. 2) IPA pwpolicy prevented the chgange # ssh fbar at ipa.example.com fbar at ipa.example.com's password: Password expired. Change your password now. Last login: Tue Oct 9 02:44:31 2012 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: Retype new password: Password change failed. Server message: Password does not contain enough character classes Password not changed. passwd: Authentication token manipulation error Connection to ipa.example.com closed. Martin From sigbjorn at nixtra.com Tue Oct 9 09:01:05 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 9 Oct 2012 11:01:05 +0200 (CEST) Subject: [Freeipa-users] sudo questions In-Reply-To: <50735E16.5060404@redhat.com> References: <50734DE8.1090802@nixtra.com> <50735E16.5060404@redhat.com> Message-ID: <19496.213.225.75.97.1349773265.squirrel@www.nixtra.com> On Tue, October 9, 2012 01:13, Dmitri Pal wrote: > On 10/08/2012 06:04 PM, Sigbjorn Lie wrote: > >> Hi, >> > > > Thank you for the report! > > >> >> I've been testing the sudo integration with IPA and I came across some >> questions: >> >> >> 1. When I disable or delete a sudo rule, it's not removed from the >> ou=sudoers until I restart the directory server. Am I doing something wrong? >> (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) >> >> > > This might be a bug in the compat plugin. The internal tree is reflected > into the standard sudo schema that is supposed to be kept in sync with the internal tree. However I > would be surprised if there is actually a bug. > I definitely still saw the rules in ou=sudoers even though I disabled or deleted the rules. However the cn=sudo tree was instantly updated. Could someone else test and see if they see the same behaviour? >> 2. Perhaps the documentation should mention creating a rule called >> "defaults" to put default options for all sudo rules in. Or even >> better having one created by default with a fresh IPA installation. It took me a few seconds to >> figure out where to put default options for all sudo rules. > > Can you please open an RFE in trac? > https://fedorahosted.org/freeipa > Ok. > > >> >> 3. sudo integration with SSSD does not work when anonymous LDAP >> authentication is disabled at the server. Enabling verbose logging in SSSD seem to suggest that >> it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) >> > > Which integration you are trying? The one that was tech preview in 1.8? > The one that makes SSSD cache sudo rules? It was significantly rewritten > in 1.9. Can you please try with 1.9? > This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in the next update of RHEL 6? > >> >> 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make >> sudo display these options as errors when sudo debugging is enabled (sudoers_debug 1 in >> /etc/ldap.conf or /etc/sudo-ldap.conf): >> sudo: unknown defaults entry `env_keep ' >> > > Yes. This is a known issue already filed as a ticket. > OK > >> >> 5. It would be great to have a set of sudo commands and a set of sudo >> command groups installed by default. > > Can you make a proposal about what groups would you like to see in an RFE? > https://fedorahosted.org/freeipa > Sure. I do believe in having only 1 sudoers source, either a file or ldap. So I I believe the contents of the file /etc/sudoers distributed with the sudoers package is a good starting point. > > >> >> 6. Adding a sudo command having multiple commands listed (such as: >> "/sbin/route, /sbin/ifconfig, /bin/ping >> > ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf >> ig,%20/sbin/mii-tool>") is allowed in IPA and does list it correctly as allowed commands when >> doing "sudo -l", however attempting to execute one of the commands in the list using sudo fails. >> >> > > Can you please try SSSD 1.9? Sure, but I'm not sure how that is going to matter as this is sudo returning an error. How is it expected to be different when the information is coming from a different source? I believe we have to do the LDAP way and not the SSSD way in production though as we have clients such as older RHEL and Solaris as well besides RHEL 6. So this should be fixed regardsless of where the sudo source is coming from. And I believe we are not alone here in having a mixed environment... :) File a bug? Regards, Siggi From sigbjorn at nixtra.com Tue Oct 9 09:02:37 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 9 Oct 2012 11:02:37 +0200 (CEST) Subject: [Freeipa-users] sudo questions In-Reply-To: <20121009055958.GH685@hendrix.brq.redhat.com> References: <50734DE8.1090802@nixtra.com> <20121009055958.GH685@hendrix.brq.redhat.com> Message-ID: <19859.213.225.75.97.1349773357.squirrel@www.nixtra.com> On Tue, October 9, 2012 07:59, Jakub Hrozek wrote: > On Tue, Oct 09, 2012 at 12:04:24AM +0200, Sigbjorn Lie wrote: > >> Hi, >> >> > > Hi Siggi, > > >> 3. sudo integration with SSSD does not work when anonymous LDAP >> authentication is disabled at the server. Enabling verbose logging in SSSD seem to suggest that >> it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) >> > > This is a known limitation of both 1.8 and 1.9. SSSD-1.9 documentation > includes an example on how to configure the sudo provider against an IPA server: > http://jhrozek.fedorapeople.org/sssd/1.9.1/man/sssd-sudo.5.html > > > We're tracking creating a native IPA sudo backend in SSSD-1.10: > https://fedorahosted.org/sssd/ticket/1108 > OK > >> 6. Adding a sudo command having multiple commands listed (such as: >> "/sbin/route, /sbin/ifconfig, /bin/ping >> > lient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwcon >> fig,%20/sbin/mii-tool>") is allowed in IPA and does list it correctly as allowed commands when >> doing "sudo -l", however attempting to execute one of the commands in the list using sudo fails. >> > > This was with SSSD or nss-pam-ldapd? ldap directly, not sssd. regards, Siggi From simo at redhat.com Tue Oct 9 12:27:58 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 09 Oct 2012 08:27:58 -0400 Subject: [Freeipa-users] confusing users In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1349785678.26127.145.camel@willson.li.ssimo.org> On Mon, 2012-10-08 at 22:59 +0000, Steven Jones wrote: > Hi, > > When a user logs in for the first time nad they have to set a new > password, if it doesnt meet the passowrd standard/policy it fails with > a "authentication token manipulation error" is it possible to get that > changed so it says "password does not meet policy"? Steven, I think this is a bug in RHEL, and should be fixed in the next update. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 9 14:08:48 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 10:08:48 -0400 Subject: [Freeipa-users] sudo questions In-Reply-To: <19496.213.225.75.97.1349773265.squirrel@www.nixtra.com> References: <50734DE8.1090802@nixtra.com> <50735E16.5060404@redhat.com> <19496.213.225.75.97.1349773265.squirrel@www.nixtra.com> Message-ID: <50742FF0.5020105@redhat.com> Sigbjorn Lie wrote: > > > > On Tue, October 9, 2012 01:13, Dmitri Pal wrote: >> On 10/08/2012 06:04 PM, Sigbjorn Lie wrote: >> >>> Hi, >>> >> >> >> Thank you for the report! >> >> >>> >>> I've been testing the sudo integration with IPA and I came across some >>> questions: >>> >>> >>> 1. When I disable or delete a sudo rule, it's not removed from the >>> ou=sudoers until I restart the directory server. Am I doing something wrong? >>> (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) >>> >>> >> >> This might be a bug in the compat plugin. The internal tree is reflected >> into the standard sudo schema that is supposed to be kept in sync with the internal tree. However I >> would be surprised if there is actually a bug. >> > > I definitely still saw the rules in ou=sudoers even though I disabled or deleted the rules. > However the cn=sudo tree was instantly updated. > > Could someone else test and see if they see the same behaviour? > > >>> 2. Perhaps the documentation should mention creating a rule called >>> "defaults" to put default options for all sudo rules in. Or even >>> better having one created by default with a fresh IPA installation. It took me a few seconds to >>> figure out where to put default options for all sudo rules. >> >> Can you please open an RFE in trac? >> https://fedorahosted.org/freeipa >> > > Ok. > > >> >> >>> >>> 3. sudo integration with SSSD does not work when anonymous LDAP >>> authentication is disabled at the server. Enabling verbose logging in SSSD seem to suggest that >>> it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) >>> >> >> Which integration you are trying? The one that was tech preview in 1.8? >> The one that makes SSSD cache sudo rules? It was significantly rewritten >> in 1.9. Can you please try with 1.9? >> > > This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in the next update of RHEL 6? > >> >>> >>> 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make >>> sudo display these options as errors when sudo debugging is enabled (sudoers_debug 1 in >>> /etc/ldap.conf or /etc/sudo-ldap.conf): >>> sudo: unknown defaults entry `env_keep ' >>> >> >> Yes. This is a known issue already filed as a ticket. >> > > OK > >> >>> >>> 5. It would be great to have a set of sudo commands and a set of sudo >>> command groups installed by default. >> >> Can you make a proposal about what groups would you like to see in an RFE? >> https://fedorahosted.org/freeipa >> > > Sure. I do believe in having only 1 sudoers source, either a file or ldap. So I I believe the > contents of the file /etc/sudoers distributed with the sudoers package is a good starting point. > > > > >> >> >>> >>> 6. Adding a sudo command having multiple commands listed (such as: >>> "/sbin/route, /sbin/ifconfig, /bin/ping >>> >> ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf >>> ig,%20/sbin/mii-tool>") is allowed in IPA and does list it correctly as allowed commands when >>> doing "sudo -l", however attempting to execute one of the commands in the list using sudo fails. >>> >>> >> >> Can you please try SSSD 1.9? > > Sure, but I'm not sure how that is going to matter as this is sudo returning an error. How is it > expected to be different when the information is coming from a different source? > > I believe we have to do the LDAP way and not the SSSD way in production though as we have clients > such as older RHEL and Solaris as well besides RHEL 6. So this should be fixed regardsless of > where the sudo source is coming from. And I believe we are not alone here in having a mixed > environment... :) Your command is allowing a user to pass the arguments /sbin/ifconfig, /bin/ping to /sbin/iparoute, (note the commas). A sudo command is a single invocation of a command. rob From sigbjorn at nixtra.com Tue Oct 9 14:15:02 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Tue, 09 Oct 2012 16:15:02 +0200 Subject: [Freeipa-users] sudo questions In-Reply-To: <50742FF0.5020105@redhat.com> References: <50734DE8.1090802@nixtra.com> <50735E16.5060404@redhat.com> <19496.213.225.75.97.1349773265.squirrel@www.nixtra.com> <50742FF0.5020105@redhat.com> Message-ID: <50743166.4040802@nixtra.com> On 10/09/2012 04:08 PM, Rob Crittenden wrote: > Sigbjorn Lie wrote: >> >> >> >> On Tue, October 9, 2012 01:13, Dmitri Pal wrote: >>> On 10/08/2012 06:04 PM, Sigbjorn Lie wrote: >>> >>>> Hi, >>>> >>> >>> >>> Thank you for the report! >>> >>> >>>> >>>> I've been testing the sudo integration with IPA and I came across some >>>> questions: >>>> >>>> >>>> 1. When I disable or delete a sudo rule, it's not removed from the >>>> ou=sudoers until I restart the directory server. Am I doing >>>> something wrong? >>>> (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) >>>> >>>> >>> >>> This might be a bug in the compat plugin. The internal tree is >>> reflected >>> into the standard sudo schema that is supposed to be kept in sync >>> with the internal tree. However I >>> would be surprised if there is actually a bug. >>> >> >> I definitely still saw the rules in ou=sudoers even though I disabled >> or deleted the rules. >> However the cn=sudo tree was instantly updated. >> >> Could someone else test and see if they see the same behaviour? >> >> >>>> 2. Perhaps the documentation should mention creating a rule called >>>> "defaults" to put default options for all sudo rules in. Or even >>>> better having one created by default with a fresh IPA installation. >>>> It took me a few seconds to >>>> figure out where to put default options for all sudo rules. >>> >>> Can you please open an RFE in trac? >>> https://fedorahosted.org/freeipa >>> >> >> Ok. >> >> >>> >>> >>>> >>>> 3. sudo integration with SSSD does not work when anonymous LDAP >>>> authentication is disabled at the server. Enabling verbose logging >>>> in SSSD seem to suggest that >>>> it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) >>>> >>> >>> Which integration you are trying? The one that was tech preview in 1.8? >>> The one that makes SSSD cache sudo rules? It was significantly >>> rewritten >>> in 1.9. Can you please try with 1.9? >>> >> >> This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in >> the next update of RHEL 6? >> >>> >>>> >>>> 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make >>>> sudo display these options as errors when sudo debugging is enabled >>>> (sudoers_debug 1 in >>>> /etc/ldap.conf or /etc/sudo-ldap.conf): >>>> sudo: unknown defaults entry `env_keep ' >>>> >>> >>> Yes. This is a known issue already filed as a ticket. >>> >> >> OK >> >>> >>>> >>>> 5. It would be great to have a set of sudo commands and a set of sudo >>>> command groups installed by default. >>> >>> Can you make a proposal about what groups would you like to see in >>> an RFE? >>> https://fedorahosted.org/freeipa >>> >> >> Sure. I do believe in having only 1 sudoers source, either a file or >> ldap. So I I believe the >> contents of the file /etc/sudoers distributed with the sudoers >> package is a good starting point. >> >> >> >> >>> >>> >>>> >>>> 6. Adding a sudo command having multiple commands listed (such as: >>>> "/sbin/route, /sbin/ifconfig, /bin/ping >>>> >>> >>>> ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf >>>> >>>> ig,%20/sbin/mii-tool>") is allowed in IPA and does list it >>>> correctly as allowed commands when >>>> doing "sudo -l", however attempting to execute one of the commands >>>> in the list using sudo fails. >>>> >>>> >>> >>> Can you please try SSSD 1.9? >> >> Sure, but I'm not sure how that is going to matter as this is sudo >> returning an error. How is it >> expected to be different when the information is coming from a >> different source? >> >> I believe we have to do the LDAP way and not the SSSD way in >> production though as we have clients >> such as older RHEL and Solaris as well besides RHEL 6. So this should >> be fixed regardsless of >> where the sudo source is coming from. And I believe we are not alone >> here in having a mixed >> environment... :) > > Your command is allowing a user to pass the arguments /sbin/ifconfig, > /bin/ping to /sbin/iparoute, (note the commas). A sudo command is a > single invocation of a command. > > rob > I am well aware of that. :) However that is an allowed syntax in file based sudoers. I believe there should be a syntax checking in IPA when adding sudo commands since it's not working with ldap based sudoers. Regards, Siggi From rcritten at redhat.com Tue Oct 9 14:27:26 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 09 Oct 2012 10:27:26 -0400 Subject: [Freeipa-users] sudo questions In-Reply-To: <50743166.4040802@nixtra.com> References: <50734DE8.1090802@nixtra.com> <50735E16.5060404@redhat.com> <19496.213.225.75.97.1349773265.squirrel@www.nixtra.com> <50742FF0.5020105@redhat.com> <50743166.4040802@nixtra.com> Message-ID: <5074344E.80804@redhat.com> Sigbjorn Lie wrote: > On 10/09/2012 04:08 PM, Rob Crittenden wrote: >> Sigbjorn Lie wrote: >>> >>> >>> >>> On Tue, October 9, 2012 01:13, Dmitri Pal wrote: >>>> On 10/08/2012 06:04 PM, Sigbjorn Lie wrote: >>>> >>>>> Hi, >>>>> >>>> >>>> >>>> Thank you for the report! >>>> >>>> >>>>> >>>>> I've been testing the sudo integration with IPA and I came across some >>>>> questions: >>>>> >>>>> >>>>> 1. When I disable or delete a sudo rule, it's not removed from the >>>>> ou=sudoers until I restart the directory server. Am I doing >>>>> something wrong? >>>>> (389-ds-base-1.2.10.2-20.el6_3.x86_64, slapi-nis-0.40-1.el6.x86_64) >>>>> >>>>> >>>> >>>> This might be a bug in the compat plugin. The internal tree is >>>> reflected >>>> into the standard sudo schema that is supposed to be kept in sync >>>> with the internal tree. However I >>>> would be surprised if there is actually a bug. >>>> >>> >>> I definitely still saw the rules in ou=sudoers even though I disabled >>> or deleted the rules. >>> However the cn=sudo tree was instantly updated. >>> >>> Could someone else test and see if they see the same behaviour? >>> >>> >>>>> 2. Perhaps the documentation should mention creating a rule called >>>>> "defaults" to put default options for all sudo rules in. Or even >>>>> better having one created by default with a fresh IPA installation. >>>>> It took me a few seconds to >>>>> figure out where to put default options for all sudo rules. >>>> >>>> Can you please open an RFE in trac? >>>> https://fedorahosted.org/freeipa >>>> >>> >>> Ok. >>> >>> >>>> >>>> >>>>> >>>>> 3. sudo integration with SSSD does not work when anonymous LDAP >>>>> authentication is disabled at the server. Enabling verbose logging >>>>> in SSSD seem to suggest that >>>>> it's attempting anonymous auth only. (sssd-1.8.4-14.fc17.x86_64) >>>>> >>>> >>>> Which integration you are trying? The one that was tech preview in 1.8? >>>> The one that makes SSSD cache sudo rules? It was significantly >>>> rewritten >>>> in 1.9. Can you please try with 1.9? >>>> >>> >>> This was F17. There is F17 packages for 1.9 somewhere? Will 1.9 be in >>> the next update of RHEL 6? >>> >>>> >>>>> >>>>> 4. Having spaces in sudo options (such as "env_keep = 'ENV_VAR'") make >>>>> sudo display these options as errors when sudo debugging is enabled >>>>> (sudoers_debug 1 in >>>>> /etc/ldap.conf or /etc/sudo-ldap.conf): >>>>> sudo: unknown defaults entry `env_keep ' >>>>> >>>> >>>> Yes. This is a known issue already filed as a ticket. >>>> >>> >>> OK >>> >>>> >>>>> >>>>> 5. It would be great to have a set of sudo commands and a set of sudo >>>>> command groups installed by default. >>>> >>>> Can you make a proposal about what groups would you like to see in >>>> an RFE? >>>> https://fedorahosted.org/freeipa >>>> >>> >>> Sure. I do believe in having only 1 sudoers source, either a file or >>> ldap. So I I believe the >>> contents of the file /etc/sudoers distributed with the sudoers >>> package is a good starting point. >>> >>> >>> >>> >>>> >>>> >>>>> >>>>> 6. Adding a sudo command having multiple commands listed (such as: >>>>> "/sbin/route, /sbin/ifconfig, /bin/ping >>>>> >>>> >>>>> ient,%20/usr/bin/net,%20/sbin/iptables,%20/usr/bin/%20rfcomm,%20/usr/bin/wvdial,%20/sbin/iwconf >>>>> >>>>> ig,%20/sbin/mii-tool>") is allowed in IPA and does list it >>>>> correctly as allowed commands when >>>>> doing "sudo -l", however attempting to execute one of the commands >>>>> in the list using sudo fails. >>>>> >>>>> >>>> >>>> Can you please try SSSD 1.9? >>> >>> Sure, but I'm not sure how that is going to matter as this is sudo >>> returning an error. How is it >>> expected to be different when the information is coming from a >>> different source? >>> >>> I believe we have to do the LDAP way and not the SSSD way in >>> production though as we have clients >>> such as older RHEL and Solaris as well besides RHEL 6. So this should >>> be fixed regardsless of >>> where the sudo source is coming from. And I believe we are not alone >>> here in having a mixed >>> environment... :) >> >> Your command is allowing a user to pass the arguments /sbin/ifconfig, >> /bin/ping to /sbin/iparoute, (note the commas). A sudo command is a >> single invocation of a command. >> >> rob >> > I am well aware of that. :) > > However that is an allowed syntax in file based sudoers. > > I believe there should be a syntax checking in IPA when adding sudo > commands since it's not working with ldap based sudoers. > > > Regards, > Siggi > I'm just not sure how we would know, except maybe to detect the commas and warn the user. If you'd like this enhancement can you open a ticket on our trac? thanks rob From Steven.Jones at vuw.ac.nz Tue Oct 9 19:44:44 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 9 Oct 2012 19:44:44 +0000 Subject: [Freeipa-users] confusing users In-Reply-To: <5073CA13.8040205@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5073CA13.8040205@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E54B8@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The user was on ssh. RHEL6 64bit. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Martin Kosek [mkosek at redhat.com] Sent: Tuesday, 9 October 2012 7:54 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] confusing users On 10/09/2012 12:59 AM, Steven Jones wrote: > Hi, > > When a user logs in for the first time nad they have to set a new password, if > it doesnt meet the passowrd standard/policy it fails with a "authentication > token manipulation error" is it possible to get that changed so it says > "password does not meet policy"? > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > Hello Steven, what service did you use to log in (package versions may help too)? When I tried ssh-ing a new user or login via login terminal, I got an explaining error message: 1) PAM prevented the change # ssh fbar at ipa.example.com fbar at ipa.example.com's password: Password expired. Change your password now. Last login: Tue Oct 9 02:44:19 2012 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: BAD PASSWORD: The password is shorter than 8 characters New password: BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word New password: Retype new password: Connection to ipa.example.com closed. 2) IPA pwpolicy prevented the chgange # ssh fbar at ipa.example.com fbar at ipa.example.com's password: Password expired. Change your password now. Last login: Tue Oct 9 02:44:31 2012 from 10.0.0.1 WARNING: Your password has expired. You must change your password now and login again! Changing password for user fbar. Current Password: New password: Retype new password: Password change failed. Server message: Password does not contain enough character classes Password not changed. passwd: Authentication token manipulation error Connection to ipa.example.com closed. Martin From mkosek at redhat.com Wed Oct 10 06:28:55 2012 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 10 Oct 2012 08:28:55 +0200 Subject: [Freeipa-users] confusing users In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E54B8@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E5050@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5073CA13.8040205@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546E54B8@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <507515A7.7060706@redhat.com> RHEL6 is quite a broad specification :-) There are 3 additional minor numbers and the fourth is coming. But as Simo suggested in this thread, this issue should be fixed in next RHEL release. I could not reproduce in Fedora too, you can check my ssh outputs below - a reason why the new password is rejected is returned to user. Martin On 10/09/2012 09:44 PM, Steven Jones wrote: > Hi, > > The user was on ssh. > > RHEL6 64bit. > > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Martin Kosek [mkosek at redhat.com] > Sent: Tuesday, 9 October 2012 7:54 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] confusing users > > On 10/09/2012 12:59 AM, Steven Jones wrote: >> Hi, >> >> When a user logs in for the first time nad they have to set a new password, if >> it doesnt meet the passowrd standard/policy it fails with a "authentication >> token manipulation error" is it possible to get that changed so it says >> "password does not meet policy"? >> >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> > > Hello Steven, > > what service did you use to log in (package versions may help too)? When I > tried ssh-ing a new user or login via login terminal, I got an explaining error > message: > > 1) PAM prevented the change > > # ssh fbar at ipa.example.com > fbar at ipa.example.com's password: > Password expired. Change your password now. > Last login: Tue Oct 9 02:44:19 2012 from 10.0.0.1 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user fbar. > Current Password: > New password: > BAD PASSWORD: The password is shorter than 8 characters > New password: > BAD PASSWORD: The password fails the dictionary check - it is based on a > dictionary word > New password: > Retype new password: Connection to ipa.example.com closed. > > 2) IPA pwpolicy prevented the chgange > > # ssh fbar at ipa.example.com > fbar at ipa.example.com's password: > Password expired. Change your password now. > Last login: Tue Oct 9 02:44:31 2012 from 10.0.0.1 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user fbar. > Current Password: > New password: > Retype new password: > Password change failed. Server message: Password does not contain enough > character classes > > Password not changed. > passwd: Authentication token manipulation error > Connection to ipa.example.com closed. > > Martin > > From grimme at atix.de Wed Oct 10 15:11:56 2012 From: grimme at atix.de (Marc Grimme) Date: Wed, 10 Oct 2012 17:11:56 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort Message-ID: <5075903C.9070909@atix.de> Hello together, we are running IPA on RHEL6.3 for quite some time. We are also using IPA to provide the LDAP backend for our samba configuration. Normally everything is running quite ok. But from time to time some people inform me that their samba password is not in sync with their password in IPA. Mostly this is working but a few different people are informing me about that. So is there a way to "resync" the password to the ones in LDAP (userPassword, sambaNTPassword)? Thanks for your help. Regards Marc. -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From simo at redhat.com Wed Oct 10 15:54:22 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Oct 2012 11:54:22 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <5075903C.9070909@atix.de> References: <5075903C.9070909@atix.de> Message-ID: <1349884462.3879.35.camel@willson.li.ssimo.org> On Wed, 2012-10-10 at 17:11 +0200, Marc Grimme wrote: > Hello together, > we are running IPA on RHEL6.3 for quite some time. > We are also using IPA to provide the LDAP backend for our samba > configuration. > Normally everything is running quite ok. > > But from time to time some people inform me that their samba password is > not in sync with their password in IPA. > Mostly this is working but a few different people are informing me about > that. > So is there a way to "resync" the password to the ones in LDAP > (userPassword, sambaNTPassword)? We do not have code to do that now (although we have some code in 3.0 that is capable of doing that so it is technically possible), but this shouldn't happen in the first place. Do you have any information about how the password was changed by these users ? Are you allowing samba to change the password ? If so are you using the option 'ldap sync only = Only' ? If you do not use this setting that is most likely the problem. If you do then it may be a bug in samba. Have you given samba access for writing to the sambaNTPassword attribute ? (you shouldn't samba should be allowed only to read). Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Wed Oct 10 22:09:53 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 10 Oct 2012 22:09:53 +0000 Subject: [Freeipa-users] F5 unit / APM module Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, The above has the capability to link to AD for authentication, can Redhat engage with F5 and get a similar thing for IPA? (or does it exist?) regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Thu Oct 11 01:02:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 10 Oct 2012 21:02:08 -0400 Subject: [Freeipa-users] F5 unit / APM module In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50761A90.1080102@redhat.com> On 10/10/2012 06:09 PM, Steven Jones wrote: > Hi, > > The above has the capability to link to AD for authentication, can Redhat engage with F5 and get a similar thing for IPA? (or does it exist?) In upcoming version directory server has a pass-through plugin that allows passing the authentication to the external source via PAM. This was added to ease the burden of password syncing. You might want to explore and try this capability. It will be in tech preview in 6.4. It should be already available in the 1.2.11 Fedora DS bits that you can try. http://port389.org/wiki/Howto:PAM_Pass_Through > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Thu Oct 11 01:47:33 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 01:47:33 +0000 Subject: [Freeipa-users] F5 unit / APM module In-Reply-To: <50761A90.1080102@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz>, <50761A90.1080102@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6A6E@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, hehe, I remember watching Simo on youtube some years back, he said something along the lines of IPA as "simple" targeting admins from 7 to 100 years old......beginning to feel im outside of that criteria!!!! :) btw, http://www.youtube.com/watch?v=7rljVIVHT6o (your tagged simo).... This is starting to get awfully involved! ;] Still worth a look, thanks. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Thursday, 11 October 2012 2:02 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] F5 unit / APM module On 10/10/2012 06:09 PM, Steven Jones wrote: > Hi, > > The above has the capability to link to AD for authentication, can Redhat engage with F5 and get a similar thing for IPA? (or does it exist?) In upcoming version directory server has a pass-through plugin that allows passing the authentication to the external source via PAM. This was added to ease the burden of password syncing. You might want to explore and try this capability. It will be in tech preview in 6.4. It should be already available in the 1.2.11 Fedora DS bits that you can try. http://port389.org/wiki/Howto:PAM_Pass_Through > > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Thu Oct 11 01:59:25 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 10 Oct 2012 21:59:25 -0400 Subject: [Freeipa-users] F5 unit / APM module In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6A6E@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz> , <50761A90.1080102@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546E6A6E@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <1349920765.10587.20.camel@willson.li.ssimo.org> On Thu, 2012-10-11 at 01:47 +0000, Steven Jones wrote: > Hi, > > hehe, I remember watching Simo on youtube some years back, he said > something along the lines of IPA as "simple" targeting admins from 7 > to 100 years old......beginning to feel im outside of that > criteria!!!! > > :) > > btw, > > http://www.youtube.com/watch?v=7rljVIVHT6o > > (your tagged simo).... The Net does not forget! The Net does not forgive! :) > This is starting to get awfully involved! > > ;] > > Still worth a look, thanks. I still think we are on the right path when it comes to simplify a lot of the bits with tie together. Hopefully it will improve as time pass and some of the roughest edges are worn down. Simo. -- Simo Sorce * Red Hat, Inc * New York From Steven.Jones at vuw.ac.nz Thu Oct 11 02:12:14 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 02:12:14 +0000 Subject: [Freeipa-users] F5 unit / APM module In-Reply-To: <1349920765.10587.20.camel@willson.li.ssimo.org> References: <833D8E48405E064EBC54C84EC6B36E40546E675E@STAWINCOX10MBX1.staff.vuw.ac.nz> , <50761A90.1080102@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546E6A6E@STAWINCOX10MBX1.staff.vuw.ac.nz>, <1349920765.10587.20.camel@willson.li.ssimo.org> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6A9D@STAWINCOX10MBX1.staff.vuw.ac.nz> It sure does not....(forget or forgive) :) Right path, yes.... I think the biggest thing is the goal posts seem to be receding as fast as you run forward....everyone wants more complex and interlinked systems to make their life "easier" and more "productive".... I blame the salesmen, they tell clients its all possible and easy........ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Simo Sorce [simo at redhat.com] Sent: Thursday, 11 October 2012 2:59 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] F5 unit / APM module On Thu, 2012-10-11 at 01:47 +0000, Steven Jones wrote: > Hi, > > hehe, I remember watching Simo on youtube some years back, he said > something along the lines of IPA as "simple" targeting admins from 7 > to 100 years old......beginning to feel im outside of that > criteria!!!! > > :) > > btw, > > http://www.youtube.com/watch?v=7rljVIVHT6o > > (your tagged simo).... The Net does not forget! The Net does not forgive! :) > This is starting to get awfully involved! > > ;] > > Still worth a look, thanks. I still think we are on the right path when it comes to simplify a lot of the bits with tie together. Hopefully it will improve as time pass and some of the roughest edges are worn down. Simo. -- Simo Sorce * Red Hat, Inc * New York From grimme at atix.de Thu Oct 11 07:43:06 2012 From: grimme at atix.de (Marc Grimme) Date: Thu, 11 Oct 2012 09:43:06 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1349884462.3879.35.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> Message-ID: <5076788A.6050703@atix.de> On Mi 10 Okt 2012 17:54:22 CEST, Simo Sorce wrote: > On Wed, 2012-10-10 at 17:11 +0200, Marc Grimme wrote: >> Hello together, >> we are running IPA on RHEL6.3 for quite some time. >> We are also using IPA to provide the LDAP backend for our samba >> configuration. >> Normally everything is running quite ok. >> >> But from time to time some people inform me that their samba password is >> not in sync with their password in IPA. >> Mostly this is working but a few different people are informing me about >> that. >> So is there a way to "resync" the password to the ones in LDAP >> (userPassword, sambaNTPassword)? > > We do not have code to do that now (although we have some code in 3.0 > that is capable of doing that so it is technically possible), but this > shouldn't happen in the first place. > > Do you have any information about how the password was changed by these > users ? They are changing their passwords via ssh, sssd (kpasswd underneath) or directly over kpasswd. BTW: What would be the recommended way to re change their password afterwards again? > > Are you allowing samba to change the password ? Probably (ldap passwd sync=Yes). Up to now I recommended to use ssh/sssd combination for passwd change to those users. > > If so are you using the option 'ldap sync only = Only' ? If you do not > use this setting that is most likely the problem. > If you do then it may be a bug in samba. I'm using samba 3.5 (part of RHEL6) and there seems to be no option ldap sync. The only relevant option I've set is ldap passwd sync = Yes. > > Have you given samba access for writing to the sambaNTPassword > attribute ? > (you shouldn't samba should be allowed only to read). Not that I know of. How can I do this? > > Simo. > -- -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From jlinoff at tabula.com Thu Oct 11 09:44:04 2012 From: jlinoff at tabula.com (Joe Linoff) Date: Thu, 11 Oct 2012 02:44:04 -0700 Subject: [Freeipa-users] free-ipa 2.2 - login fails on some hosts but not others Message-ID: <8AD4194C251EC74CB897E261038F4478012E8387@mantaray.tabula.com> Hi: I am using free-ipa 2.2 to manage LDAP/DNS for about a dozen CentOS 6.3 servers on a small network. I am having a problem where a user cannot log into a host even though "ipa hbactest" says the he is authorized. This user can log into other hosts where "ipa hbactest" says he is authorized. Here is the problem in a nutshell: # Works for host1 $ ssh user1 at host1 user1 at host1's password: Last login ... [user1 at host1 ~] echo "SUCCESS" SUCCESS # Fails for host2 $ ssh user1 at host2 Password: Permission denied (publickey, gssapi-keyex, gssapi-with-mic, keyboard-interactive). # hbactest $ ipa hbactest --user=user1 --host=host1 --service==sshd -------------------- Access granted: True -------------------- # hbactest $ ipa hbactest --user=user1 --host=host2 --service==sshd -------------------- Access granted: True -------------------- It seems that free-ipa thinks that everything is copacetic so there must be something different on the hosts. I looked at /etc/ssh/sshd.conf, /etc/nsswitch.conf and /etc/sssd/sssd.conf on both hosts but didn't see anything that looked out of whack. I also tried "ssh -vvv" but wasn't sure how to interpret the results. I am using an NFS automount /home setup so both are using the same ~/.ssh. I am not sure how to debug this. Do you know why the password prompt is different? That may be a clue. Can you suggest some other things that I can try? Any help would be greatly appreciated. Thank you. Regards, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Oct 11 09:56:42 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 11 Oct 2012 11:56:42 +0200 Subject: [Freeipa-users] free-ipa 2.2 - login fails on some hosts but not others In-Reply-To: <8AD4194C251EC74CB897E261038F4478012E8387@mantaray.tabula.com> References: <8AD4194C251EC74CB897E261038F4478012E8387@mantaray.tabula.com> Message-ID: <20121011095642.GK30197@hendrix.redhat.com> On Thu, Oct 11, 2012 at 02:44:04AM -0700, Joe Linoff wrote: > I am not sure how to debug this. I would start with attaching the relevant contents of /var/log/secure. Do they differ on the host that succeeds vs the one that fails? From simo at redhat.com Thu Oct 11 12:37:57 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Oct 2012 08:37:57 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <5076788A.6050703@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> Message-ID: <1349959077.10587.30.camel@willson.li.ssimo.org> On Thu, 2012-10-11 at 09:43 +0200, Marc Grimme wrote: > On Mi 10 Okt 2012 17:54:22 CEST, Simo Sorce wrote: > > On Wed, 2012-10-10 at 17:11 +0200, Marc Grimme wrote: > >> Hello together, > >> we are running IPA on RHEL6.3 for quite some time. > >> We are also using IPA to provide the LDAP backend for our samba > >> configuration. > >> Normally everything is running quite ok. > >> > >> But from time to time some people inform me that their samba password is > >> not in sync with their password in IPA. > >> Mostly this is working but a few different people are informing me about > >> that. > >> So is there a way to "resync" the password to the ones in LDAP > >> (userPassword, sambaNTPassword)? > > > > We do not have code to do that now (although we have some code in 3.0 > > that is capable of doing that so it is technically possible), but this > > shouldn't happen in the first place. > > > > Do you have any information about how the password was changed by these > > users ? > They are changing their passwords via ssh, sssd (kpasswd underneath) or > directly over kpasswd. > > BTW: What would be the recommended way to re change their password > afterwards again? Those methods are fine. Are you sure the affected users didn't change their password via their Windows clients ? Are their clients joined to the samba domain ? > > Are you allowing samba to change the password ? > Probably (ldap passwd sync=Yes). Up to now I recommended to use > ssh/sssd combination for passwd change to those users. > > > > If so are you using the option 'ldap sync only = Only' ? If you do not > > use this setting that is most likely the problem. > > If you do then it may be a bug in samba. > I'm using samba 3.5 (part of RHEL6) and there seems to be no option > ldap sync. > The only relevant option I've set is ldap passwd sync = Yes. I use RHEL6 as well and the smb.conf man page has 'ldap passwd sync'' and the 'only' option. It has been in samba for a long time (I think since 3.0.x) > > Have you given samba access for writing to the sambaNTPassword > > attribute ? > > (you shouldn't samba should be allowed only to read). > Not that I know of. > How can I do this? You can do it with a custom user and custom ACIs. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Thu Oct 11 14:05:14 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Oct 2012 10:05:14 -0400 Subject: [Freeipa-users] free-ipa 2.2 - login fails on some hosts but not others In-Reply-To: <20121011095642.GK30197@hendrix.redhat.com> References: <8AD4194C251EC74CB897E261038F4478012E8387@mantaray.tabula.com> <20121011095642.GK30197@hendrix.redhat.com> Message-ID: <5076D21A.20702@redhat.com> On 10/11/2012 05:56 AM, Jakub Hrozek wrote: > On Thu, Oct 11, 2012 at 02:44:04AM -0700, Joe Linoff wrote: >> I am not sure how to debug this. > I would start with attaching the relevant contents of /var/log/secure. > Do they differ on the host that succeeds vs the one that fails? > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users May be host resolves itself to a different name than you expect/provide in the hbactest? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From grimme at atix.de Thu Oct 11 15:48:40 2012 From: grimme at atix.de (Marc Grimme) Date: Thu, 11 Oct 2012 17:48:40 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1349959077.10587.30.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> Message-ID: <5076EA58.50308@atix.de> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: > On Thu, 2012-10-11 at 09:43 +0200, Marc Grimme wrote: >> On Mi 10 Okt 2012 17:54:22 CEST, Simo Sorce wrote: >> They are changing their passwords via ssh, sssd (kpasswd underneath) or >> directly over kpasswd. >> >> BTW: What would be the recommended way to re change their password >> afterwards again? > > Those methods are fine. > Are you sure the affected users didn't change their password via their > Windows clients ? Are their clients joined to the samba domain ? No they are integrated in the Kerberos Domain of IPA but not joined to the samba domain. > >> Probably (ldap passwd sync=Yes). Up to now I recommended to use >> ssh/sssd combination for passwd change to those users. >>> >> I'm using samba 3.5 (part of RHEL6) and there seems to be no option >> ldap sync. >> The only relevant option I've set is ldap passwd sync = Yes. > > I use RHEL6 as well and the smb.conf man page has 'ldap passwd sync'' > and the 'only' option. It has been in samba for a long time (I think > since 3.0.x) Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? > >> Not that I know of. >> How can I do this? > > You can do it with a custom user and custom ACIs. > Further testing. I have a user called tuser. 1. Reset the password: ipaserver1 # ipa passwd tuser New Password: Enter New Password again to verify: ------------------------------------ Changed password for "tuser at CL.ATIX" ------------------------------------ 2. Login to another server via ssh: $ ssh tuser at methusalix2 tuser at methusalix2's password: Password expired. Change your password now. Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 WARNING: Your password has expired. You must change your password now and login again! Changing password for user tuser. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. Connection to methusalix2 closed. $ ssh tuser at methusalix2 tuser at methusalix2's password: Permission denied, please try again. tuser at methusalix2's password: Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 -bash-4.1$ => SSH Login works (Kerberos PW is set). 3. Let's browse Samba: $ smbclient -U tuser -L methusalix2 Enter tuser's password: session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE Any ideas what's going wrong? Thanks Marc. -- -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From simo at redhat.com Thu Oct 11 16:12:05 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 11 Oct 2012 12:12:05 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <5076EA58.50308@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> Message-ID: <1349971925.10587.115.camel@willson.li.ssimo.org> On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: > On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: > > On Thu, 2012-10-11 at 09:43 +0200, Marc Grimme wrote: > >> On Mi 10 Okt 2012 17:54:22 CEST, Simo Sorce wrote: > >> They are changing their passwords via ssh, sssd (kpasswd underneath) or > >> directly over kpasswd. > >> > >> BTW: What would be the recommended way to re change their password > >> afterwards again? > > > > Those methods are fine. > > Are you sure the affected users didn't change their password via their > > Windows clients ? Are their clients joined to the samba domain ? > No they are integrated in the Kerberos Domain of IPA but not joined to > the samba domain. > > > >> Probably (ldap passwd sync=Yes). Up to now I recommended to use > >> ssh/sssd combination for passwd change to those users. > >>> > >> I'm using samba 3.5 (part of RHEL6) and there seems to be no option > >> ldap sync. > >> The only relevant option I've set is ldap passwd sync = Yes. > > > > I use RHEL6 as well and the smb.conf man page has 'ldap passwd sync'' > > and the 'only' option. It has been in samba for a long time (I think > > since 3.0.x) > Ok. Sorry I'm using > ldap passwd sync=Yes > Is that wrong? Yes, you should use "ldap passwd sync = only" > >> Not that I know of. > >> How can I do this? > > > > You can do it with a custom user and custom ACIs. > > > Further testing. > I have a user called tuser. > 1. Reset the password: > ipaserver1 # ipa passwd tuser > New Password: > Enter New Password again to verify: > ------------------------------------ > Changed password for "tuser at CL.ATIX" > ------------------------------------ > 2. Login to another server via ssh: > $ ssh tuser at methusalix2 > tuser at methusalix2's password: > Password expired. Change your password now. > Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user tuser. > Current Password: > New password: > Retype new password: > passwd: all authentication tokens updated successfully. > Connection to methusalix2 closed. > $ ssh tuser at methusalix2 > tuser at methusalix2's password: > Permission denied, please try again. > tuser at methusalix2's password: > Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 > -bash-4.1$ > => SSH Login works (Kerberos PW is set). > 3. Let's browse Samba: > $ smbclient -U tuser -L methusalix2 > Enter tuser's password: > session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE > > Any ideas what's going wrong? Uhmm seem one of the samba attributes has not been properly changed ... This is IPA on RHEL6.3 ? Can you check if the use has the attribute sambaPwdMustChange set ? Apparently the IPA passoword plugin does not touch it. Simo. -- Simo Sorce * Red Hat, Inc * New York From mbarr at snap-interactive.com Thu Oct 11 16:29:44 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Thu, 11 Oct 2012 12:29:44 -0400 Subject: [Freeipa-users] Cleaning a host that is both present & not found Message-ID: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> I've got a host that's showing as both there & not there. I've checked both the gui & cli, and here's the result. --- [root at ops01 ~]# ipa host-find mdb09.ayisnap.com -------------- 1 host matched -------------- Host name: mdb09.ayisnap.com Principal name: host/mdb09.ayisnap.com at AYISNAP.COM Password: False Keytab: False Managed by: mdb09.ayisnap.com ---------------------------- Number of entries returned 1 ---------------------------- [root at ops01 ~]# ipa host-del mdb09.ayisnap.com ipa: ERROR: mdb09.ayisnap.com: host not found --- I suspect it's only exiting in some of the LDAP tables, but I can't tell enough about the structure to delete it from IPA, and then we can just re-add it. Anyone have any suggestions on what to do to clean this up? Matthew Barr Technical Architect E: mbarr at snap-interactive.com AIM: matthewbarr1 c: (646) 727-0535 From rmeggins at redhat.com Thu Oct 11 16:44:31 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 11 Oct 2012 10:44:31 -0600 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> Message-ID: <5076F76F.1020102@redhat.com> On 10/11/2012 10:29 AM, Matthew Barr wrote: > I've got a host that's showing as both there& not there. I've checked both the gui& cli, and here's the result. > > --- > [root at ops01 ~]# ipa host-find mdb09.ayisnap.com > -------------- > 1 host matched > -------------- > Host name: mdb09.ayisnap.com > Principal name: host/mdb09.ayisnap.com at AYISNAP.COM > Password: False > Keytab: False > Managed by: mdb09.ayisnap.com > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ops01 ~]# ipa host-del mdb09.ayisnap.com > ipa: ERROR: mdb09.ayisnap.com: host not found > > > > --- > I suspect it's only exiting in some of the LDAP tables, but I can't tell enough about the structure to delete it from IPA, and then we can just re-add it. > > > Anyone have any suggestions on what to do to clean this up? rpm -q 389-ds-base ldapsearch -xLLL -D "cn=directory manager" -W "fqdn=mdb09.ayisnap.com" > > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From mbarr at snap-interactive.com Thu Oct 11 17:06:15 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Thu, 11 Oct 2012 13:06:15 -0400 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <5076F76F.1020102@redhat.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <5076F76F.1020102@redhat.com> Message-ID: <2C132F75-95BB-49CF-BFCB-FEF9F36FCEB5@snap-interactive.com> >> I suspect it's only exiting in some of the LDAP tables, but I can't tell enough about the structure to delete it from IPA, and then we can just re-add it. >> >> >> Anyone have any suggestions on what to do to clean this up? > rpm -q 389-ds-base > > ldapsearch -xLLL -D "cn=directory manager" -W "fqdn=mdb09.ayisnap.com" I was actually able to find a decent ldap browser, which was able to show me what was going on. There was a record under accounts,computers that was named oddly, which had the internal attributes of mdb09. I deleted that, and it fixed the issue. Exactly what you recommended, but I didn't have the cli ldap skills :) Thanks! From Steven.Jones at vuw.ac.nz Thu Oct 11 19:50:23 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 19:50:23 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz> HI, Looks like I have this at present as well. The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. Meantime I have 2 machines in this state, no one can login. :/ So what they have said is, ========== Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz ========= case number is 00716456, if you have RH support maybe link it? so if its a clear bug it gets addressed. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Matthew Barr [mbarr at snap-interactive.com] Sent: Friday, 12 October 2012 5:29 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Cleaning a host that is both present & not found I've got a host that's showing as both there & not there. I've checked both the gui & cli, and here's the result. --- [root at ops01 ~]# ipa host-find mdb09.ayisnap.com -------------- 1 host matched -------------- Host name: mdb09.ayisnap.com Principal name: host/mdb09.ayisnap.com at AYISNAP.COM Password: False Keytab: False Managed by: mdb09.ayisnap.com ---------------------------- Number of entries returned 1 ---------------------------- [root at ops01 ~]# ipa host-del mdb09.ayisnap.com ipa: ERROR: mdb09.ayisnap.com: host not found --- I suspect it's only exiting in some of the LDAP tables, but I can't tell enough about the structure to delete it from IPA, and then we can just re-add it. Anyone have any suggestions on what to do to clean this up? Matthew Barr Technical Architect E: mbarr at snap-interactive.com AIM: matthewbarr1 c: (646) 727-0535 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Oct 11 19:54:14 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 19:54:14 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <5076F76F.1020102@redhat.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com>, <5076F76F.1020102@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6E98@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, My outputs are (RHEL6.3 64bit), [root at vuwunicoipam001 etc]# rpm -q 389-ds-base 389-ds-base-1.2.10.2-18.el6_3.x86_64 [root at vuwunicoipam001 etc]# ========== ipa host-del --updatedns vuwunicosldedt1.ods.vuw.ac.nz ipa: ERROR: vuwunicosldedt1.ods.vuw.ac.nz: host not found [root at vuwunicoipam001 sssd]# ldapsearch -LL -Y GSSAPI -b "dc=ods,dc=vuw,dc=ac,dc=nz" |grep sld SASL/GSSAPI authentication started SASL username: ipajonesst1 at ODS.VUW.AC.NZ SASL SSF: 56 SASL data security layer installed. dn: cn=ug-slde-admins,cn=groups,cn=compat,dc=ods,dc=vuw,dc=ac,dc=nz cn: ug-slde-admins dn: cn=hg-slde-admins,cn=ng,cn=compat,dc=ods,dc=vuw,dc=ac,dc=nz nisNetgroupTriple: (vuwunicosldedt2.ods.vuw.ac.nz,-,ods.vuw.ac.nz) cn: hg-slde-admins sudoUser: %ug-slde-admins sudoHost: vuwunicosldedt2.ods.vuw.ac.nz memberOf: cn=ug-slde-admins,cn=groups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz memberUser: cn=ug-slde-admins,cn=groups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz memberOf: cn=ug-slde-admins,cn=groups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz memberOf: cn=hg-slde-admins,cn=hostgroups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=n memberOf: cn=hg-slde-admins,cn=ng,cn=alt,dc=ods,dc=vuw,dc=ac,dc=nz cn: vuwunicosldedt2.ods.vuw.ac.nz fqdn: vuwunicosldedt2.ods.vuw.ac.nz managedBy: fqdn=vuwunicosldedt2.ods.vuw.ac.nz,cn=computers,cn=accounts,dc=ods, krbPrincipalName: host/vuwunicosldedt2.ods.vuw.ac.nz at ODS.VUW.AC.NZ serverHostName: vuwunicosldedt2 dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac idnsName: vuwunicosldedt2 dn: cn=hg-slde-admins,cn=hostgroups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz memberOf: cn=hg-slde-admins,cn=ng,cn=alt,dc=ods,dc=vuw,dc=ac,dc=nz mepManagedEntry: cn=hg-slde-admins,cn=ng,cn=alt,dc=ods,dc=vuw,dc=ac,dc=nz cn: hg-slde-admins dn: cn=hg-slde-admins,cn=ng,cn=alt,dc=ods,dc=vuw,dc=ac,dc=nz cn: hg-slde-admins memberHost: cn=hg-slde-admins,cn=hostgroups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc description: ipaNetgroup hg-slde-admins mepManagedBy: cn=hg-slde-admins,cn=hostgroups,cn=accounts,dc=ods,dc=vuw,dc=ac, dn: cn=ug-slde-admins,cn=groups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz cn: ug-slde-admins description: ug-slde-admins memberHost: cn=hg-slde-admins,cn=hostgroups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc memberUser: cn=ug-slde-admins,cn=groups,cn=accounts,dc=ods,dc=vuw,dc=ac,dc=nz cn: hb-slde-admins cn: vuwunicosldedt1.ods.vuw.ac.nz fqdn: vuwunicosldedt1.ods.vuw.ac.nz managedBy: fqdn=vuwunicosldedt1.ods.vuw.ac.nz,cn=computers,cn=accounts,dc=ods, krbPrincipalName: host/vuwunicosldedt1.ods.vuw.ac.nz at ODS.VUW.AC.NZ serverHostName: vuwunicosldedt1 [root at vuwunicoipam001 sssd]# ipa host-del --updatedns vuwunicosldedt2.ods.vuw.ac.nz ipa: ERROR: vuwunicosldedt2.ods.vuw.ac.nz: host not found [root at vuwunicoipam001 sssd]# ============= regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Rich Megginson [rmeggins at redhat.com] Sent: Friday, 12 October 2012 5:44 a.m. To: Matthew Barr Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On 10/11/2012 10:29 AM, Matthew Barr wrote: > I've got a host that's showing as both there& not there. I've checked both the gui& cli, and here's the result. > > --- > [root at ops01 ~]# ipa host-find mdb09.ayisnap.com > -------------- > 1 host matched > -------------- > Host name: mdb09.ayisnap.com > Principal name: host/mdb09.ayisnap.com at AYISNAP.COM > Password: False > Keytab: False > Managed by: mdb09.ayisnap.com > ---------------------------- > Number of entries returned 1 > ---------------------------- > [root at ops01 ~]# ipa host-del mdb09.ayisnap.com > ipa: ERROR: mdb09.ayisnap.com: host not found > > > > --- > I suspect it's only exiting in some of the LDAP tables, but I can't tell enough about the structure to delete it from IPA, and then we can just re-add it. > > > Anyone have any suggestions on what to do to clean this up? rpm -q 389-ds-base ldapsearch -xLLL -D "cn=directory manager" -W "fqdn=mdb09.ayisnap.com" > > > Matthew Barr > Technical Architect > E: mbarr at snap-interactive.com > AIM: matthewbarr1 > c: (646) 727-0535 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From mbarr at snap-interactive.com Thu Oct 11 20:25:14 2012 From: mbarr at snap-interactive.com (Matthew Barr) Date: Thu, 11 Oct 2012 16:25:14 -0400 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: > HI, > > Looks like I have this at present as well. > > The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. > > Meantime I have 2 machines in this state, no one can login. > > :/ > > So what they have said is, > > ========== > Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz > ========= ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) Matthew From rcritten at redhat.com Thu Oct 11 20:31:03 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 11 Oct 2012 16:31:03 -0400 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50772C87.3000500@redhat.com> Steven Jones wrote: > HI, > > Looks like I have this at present as well. > > The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. > > Meantime I have 2 machines in this state, no one can login. > > :/ > > So what they have said is, > > ========== > Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz > ========= > > case number is 00716456, if you have RH support maybe link it? so if its a clear bug it gets addressed. The second entry he suggests deleting is your DNS entry, that does not need to be touched. This looks like a replication conflict. The same host must have been created on two separate masters while replication was down. This will result in the nsuniqueid entry. You need to manually resolve the differences between the two but as of yet IPA doesn't provide any tools to help manage this process. Basically you'll want to merge any values from the entry whose dn is nsuniqueid=...,cn=computers to the equivalen fqdn=...,cn=computers entry. This is if you want to preserve any existing keytabs, certificates, etc. I may be fine to just remove both entries and start over. Note that you need to be careful not to orphan any service entries that may be associated with the host. You'll want to base your searches on cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz to get only the matching host(s). The delete is failing because we expect only one host to be found but two are so we throw our hands up. A better error message would make this clearer. If you look in the Apache error log you may see it returns SingleMatchExpected. rob From Steven.Jones at vuw.ac.nz Thu Oct 11 21:07:11 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 21:07:11 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Matthew Barr [mbarr at snap-interactive.com] Sent: Friday, 12 October 2012 9:25 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: > HI, > > Looks like I have this at present as well. > > The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. > > Meantime I have 2 machines in this state, no one can login. > > :/ > > So what they have said is, > > ========== > Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz > ========= ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) Matthew From Steven.Jones at vuw.ac.nz Thu Oct 11 21:09:26 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 21:09:26 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <50772C87.3000500@redhat.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <50772C87.3000500@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6EF5@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Yes I think you are spot on. Replication stopped working and we didnt notice. This server hadto be rebuilt as it didnt build properly so it got re-added to IPA and I assume two different IPA servers. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Friday, 12 October 2012 9:31 a.m. To: Steven Jones Cc: Matthew Barr; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found Steven Jones wrote: > HI, > > Looks like I have this at present as well. > > The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. > > Meantime I have 2 machines in this state, no one can login. > > :/ > > So what they have said is, > > ========== > Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz > ========= > > case number is 00716456, if you have RH support maybe link it? so if its a clear bug it gets addressed. The second entry he suggests deleting is your DNS entry, that does not need to be touched. This looks like a replication conflict. The same host must have been created on two separate masters while replication was down. This will result in the nsuniqueid entry. You need to manually resolve the differences between the two but as of yet IPA doesn't provide any tools to help manage this process. Basically you'll want to merge any values from the entry whose dn is nsuniqueid=...,cn=computers to the equivalen fqdn=...,cn=computers entry. This is if you want to preserve any existing keytabs, certificates, etc. I may be fine to just remove both entries and start over. Note that you need to be careful not to orphan any service entries that may be associated with the host. You'll want to base your searches on cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz to get only the matching host(s). The delete is failing because we expect only one host to be found but two are so we throw our hands up. A better error message would make this clearer. If you look in the Apache error log you may see it returns SingleMatchExpected. rob From rmeggins at redhat.com Thu Oct 11 21:13:00 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 11 Oct 2012 15:13:00 -0600 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5077365C.7050106@redhat.com> On 10/11/2012 03:07 PM, Steven Jones wrote: > Hi, > > yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... man ldapdelete ldapdelete -x -D "cn=directory manager" -W "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" or, to use your kerberos credentials ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Matthew Barr [mbarr at snap-interactive.com] > Sent: Friday, 12 October 2012 9:25 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found > > On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: > >> HI, >> >> Looks like I have this at present as well. >> >> The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. >> >> Meantime I have 2 machines in this state, no one can login. >> >> :/ >> >> So what they have said is, >> >> ========== >> Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz >> ========= > > ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) > > (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) > > Matthew > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Oct 11 22:10:10 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 22:10:10 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <5077365C.7050106@redhat.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5077365C.7050106@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> The web ui is still failing.... :( regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, 12 October 2012 10:13 a.m. To: Steven Jones Cc: Matthew Barr; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On 10/11/2012 03:07 PM, Steven Jones wrote: > Hi, > > yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... man ldapdelete ldapdelete -x -D "cn=directory manager" -W "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" or, to use your kerberos credentials ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Matthew Barr [mbarr at snap-interactive.com] > Sent: Friday, 12 October 2012 9:25 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found > > On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: > >> HI, >> >> Looks like I have this at present as well. >> >> The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. >> >> Meantime I have 2 machines in this state, no one can login. >> >> :/ >> >> So what they have said is, >> >> ========== >> Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz >> ========= > > ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) > > (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) > > Matthew > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Oct 11 22:16:44 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 11 Oct 2012 22:16:44 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5077365C.7050106@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz> Even after running, ========== [root at vuwunicoipam002 ~]# kinit ipajonesst1 Password for ipajonesst1 at ODS.VUW.AC.NZ: [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" SASL/GSSAPI authentication started SASL username: ipajonesst1 at ODS.VUW.AC.NZ SASL SSF: 56 SASL data security layer installed. ldap_delete: No such object (32) matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt1,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" SASL/GSSAPI authentication started SASL username: ipajonesst1 at ODS.VUW.AC.NZ SASL SSF: 56 SASL data security layer installed. ldap_delete: No such object (32) matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz [root at vuwunicoipam002 ~]# ========== regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Friday, 12 October 2012 11:10 a.m. To: Rich Megginson Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found The web ui is still failing.... :( regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, 12 October 2012 10:13 a.m. To: Steven Jones Cc: Matthew Barr; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On 10/11/2012 03:07 PM, Steven Jones wrote: > Hi, > > yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... man ldapdelete ldapdelete -x -D "cn=directory manager" -W "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" or, to use your kerberos credentials ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Matthew Barr [mbarr at snap-interactive.com] > Sent: Friday, 12 October 2012 9:25 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found > > On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: > >> HI, >> >> Looks like I have this at present as well. >> >> The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. >> >> Meantime I have 2 machines in this state, no one can login. >> >> :/ >> >> So what they have said is, >> >> ========== >> Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz >> ========= > > ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) > > (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) > > Matthew > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- A non-text attachment was scrubbed... Name: rep-slde-error-01.jpeg Type: image/jpeg Size: 45529 bytes Desc: rep-slde-error-01.jpeg URL: From rmeggins at redhat.com Fri Oct 12 00:30:25 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 11 Oct 2012 18:30:25 -0600 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5077365C.7050106@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <507764A1.6000501@redhat.com> On 10/11/2012 04:16 PM, Steven Jones wrote: > Even after running, > > ========== > [root at vuwunicoipam002 ~]# kinit ipajonesst1 > Password for ipajonesst1 at ODS.VUW.AC.NZ: > [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > SASL/GSSAPI authentication started > SASL username: ipajonesst1 at ODS.VUW.AC.NZ > SASL SSF: 56 > SASL data security layer installed. > ldap_delete: No such object (32) > matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz > [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt1,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > SASL/GSSAPI authentication started > SASL username: ipajonesst1 at ODS.VUW.AC.NZ > SASL SSF: 56 > SASL data security layer installed. > ldap_delete: No such object (32) > matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz > [root at vuwunicoipam002 ~]# > ========== Ok, then I'm not sure why the RH support guy told you to delete an entry that doesn't exist. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Friday, 12 October 2012 11:10 a.m. > To: Rich Megginson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found > > The web ui is still failing.... > > :( > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rich Megginson [rmeggins at redhat.com] > Sent: Friday, 12 October 2012 10:13 a.m. > To: Steven Jones > Cc: Matthew Barr; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found > > On 10/11/2012 03:07 PM, Steven Jones wrote: >> Hi, >> >> yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... > man ldapdelete > > ldapdelete -x -D "cn=directory manager" -W > "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac > ,dc=nz" > > or, to use your kerberos credentials > > ldapdelete -Y GSSAPI > "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac > ,dc=nz" > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Matthew Barr [mbarr at snap-interactive.com] >> Sent: Friday, 12 October 2012 9:25 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found >> >> On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: >> >>> HI, >>> >>> Looks like I have this at present as well. >>> >>> The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. >>> >>> Meantime I have 2 machines in this state, no one can login. >>> >>> :/ >>> >>> So what they have said is, >>> >>> ========== >>> Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz >>> ========= >> ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) >> >> (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) >> >> Matthew >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Fri Oct 12 00:45:06 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Fri, 12 Oct 2012 00:45:06 +0000 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <507764A1.6000501@redhat.com> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5077365C.7050106@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <507764A1.6000501@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E701B@STAWINCOX10MBX1.staff.vuw.ac.nz> In the gui it does exist....I included an attachment of that as a screenshot but I cant delete it from the gui because it doesnt exist. :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, 12 October 2012 1:30 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On 10/11/2012 04:16 PM, Steven Jones wrote: Even after running, ========== [root at vuwunicoipam002 ~]# kinit ipajonesst1 Password for ipajonesst1 at ODS.VUW.AC.NZ: [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" SASL/GSSAPI authentication started SASL username: ipajonesst1 at ODS.VUW.AC.NZ SASL SSF: 56 SASL data security layer installed. ldap_delete: No such object (32) matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt1,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" SASL/GSSAPI authentication started SASL username: ipajonesst1 at ODS.VUW.AC.NZ SASL SSF: 56 SASL data security layer installed. ldap_delete: No such object (32) matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz [root at vuwunicoipam002 ~]# ========== Ok, then I'm not sure why the RH support guy told you to delete an entry that doesn't exist. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] Sent: Friday, 12 October 2012 11:10 a.m. To: Rich Megginson Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found The web ui is still failing.... :( regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, 12 October 2012 10:13 a.m. To: Steven Jones Cc: Matthew Barr; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found On 10/11/2012 03:07 PM, Steven Jones wrote: Hi, yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... man ldapdelete ldapdelete -x -D "cn=directory manager" -W "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" or, to use your kerberos credentials ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Matthew Barr [mbarr at snap-interactive.com] Sent: Friday, 12 October 2012 9:25 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: HI, Looks like I have this at present as well. The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. Meantime I have 2 machines in this state, no one can login. :/ So what they have said is, ========== Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz ========= ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) Matthew _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 12 01:09:18 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 11 Oct 2012 21:09:18 -0400 Subject: [Freeipa-users] Cleaning a host that is both present & not found In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <2BA4F485-012E-4F71-BCA3-46B384EF938C@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6E87@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5419BB75-0368-4F17-B85A-907DA073A36A@snap-interactive.com> <833D8E48405E064EBC54C84EC6B36E40546E6EEA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5077365C.7050106@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E6F1E@STAWINCOX10MBX1.staff.vuw.ac.nz> <833D8E48405E064EBC54C84EC6B36E40546E6F2C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50776DBE.8010305@redhat.com> On 10/11/2012 06:16 PM, Steven Jones wrote: > Even after running, > > ========== > [root at vuwunicoipam002 ~]# kinit ipajonesst1 > Password for ipajonesst1 at ODS.VUW.AC.NZ: > [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > SASL/GSSAPI authentication started > SASL username: ipajonesst1 at ODS.VUW.AC.NZ > SASL SSF: 56 > SASL data security layer installed. > ldap_delete: No such object (32) > matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz > [root at vuwunicoipam002 ~]# ldapdelete -Y GSSAPI "idnsName=vuwunicosldedt1,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz" > SASL/GSSAPI authentication started > SASL username: ipajonesst1 at ODS.VUW.AC.NZ > SASL SSF: 56 > SASL data security layer installed. > ldap_delete: No such object (32) > matched DN: idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac,dc=nz > [root at vuwunicoipam002 ~]# > ========== >From the command line do a search for all entries in your environment and dump them into a file (may take a while). Then you can open the file and search for "vuwunicosldedt" string and see what entries it can be found in. That will give a hint what is going on and what to do next. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Steven Jones [Steven.Jones at vuw.ac.nz] > Sent: Friday, 12 October 2012 11:10 a.m. > To: Rich Megginson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found > > The web ui is still failing.... > > :( > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rich Megginson [rmeggins at redhat.com] > Sent: Friday, 12 October 2012 10:13 a.m. > To: Steven Jones > Cc: Matthew Barr; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Cleaning a host that is both present & not found > > On 10/11/2012 03:07 PM, Steven Jones wrote: >> Hi, >> >> yes I have xplorer, maybe I'll do it that way as I cant figure out the ldapdelete command... > man ldapdelete > > ldapdelete -x -D "cn=directory manager" -W > "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac > ,dc=nz" > > or, to use your kerberos credentials > > ldapdelete -Y GSSAPI > "idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac > ,dc=nz" > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Matthew Barr [mbarr at snap-interactive.com] >> Sent: Friday, 12 October 2012 9:25 a.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Cleaning a host that is both present& not found >> >> On Oct 11, 2012, at 3:50 PM, Steven Jones wrote: >> >>> HI, >>> >>> Looks like I have this at present as well. >>> >>> The advice off RH support is to run an ldapdelete but Im waiting on the complete syntax off them and why its happened. >>> >>> Meantime I have 2 machines in this state, no one can login. >>> >>> :/ >>> >>> So what they have said is, >>> >>> ========== >>> Hello Steven, I am still going through all the data available in this case, but it looks like you should be able to fix this problem by deleting the following two entries using ldapdelete: dn: nsuniqueid=fdda5001-0cf511e2-8bfdc792-b25c661e,cn=computers,cn=accounts,dc =ods,dc=vuw,dc=ac,dc=nz dn: idnsName=vuwunicosldedt2,idnsname=ods.vuw.ac.nz,cn=dns,dc=ods,dc=vuw,dc=ac ,dc=nz >>> ========= >> ldapdelete would have worked, but I ended up using jxplorer to do it. Much easier for me at the time :) >> >> (i'm on a VPN link into the DC, and had access to the ldap port directly, so I could do that. Their advise does look correct, though, and matches where I found the problem.) >> >> Matthew >> >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From arthur at deus.pro Fri Oct 12 09:52:04 2012 From: arthur at deus.pro (=?koi8-r?Q?=E1=D2=D4=D5=D2_?= =?koi8-r?Q?=E6=C1=CA=DA=D5=CC=CC=C9=CE?=) Date: Fri, 12 Oct 2012 15:52:04 +0600 Subject: [Freeipa-users] dyndb-ldap in standart ldap Message-ID: <1350035524.2220.7.camel@arthur.bashnl.local> Hi, everyone! On site of the dyndb-ldap project https://fedorahosted.org/bind-dyndb-ldap/ is told that for any question I should ask here. May be it is an old question, but I didn't find anything on it. I just want to learn how to store records for dyndb-ldap in standart LDAP-server such as 389-ds or OpenLDAP. If I am fool and couldn't find it, please, show me where I can learn it (google couldn'r help me). Or may You can explain me it, and I could make documentation for it? ____________________ Best regards, Arthur From grimme at atix.de Fri Oct 12 11:20:41 2012 From: grimme at atix.de (Marc Grimme) Date: Fri, 12 Oct 2012 13:20:41 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1349971925.10587.115.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> Message-ID: <5077FD09.5090402@atix.de> Am 11.10.2012 18:12, schrieb Simo Sorce: > On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: >> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: >>> >> No they are integrated in the Kerberos Domain of IPA but not joined to >> the samba domain. >>> Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? > Yes, you should use "ldap passwd sync = only" Ok, I set it as suggested. > >> Further testing. >> I have a user called tuser. >> 1. Reset the password: >> ipaserver1 # ipa passwd tuser >> New Password: >> Enter New Password again to verify: >> ------------------------------------ >> Changed password for "tuser at CL.ATIX" >> ------------------------------------ >> 2. Login to another server via ssh: >> $ ssh tuser at methusalix2 >> tuser at methusalix2's password: >> Password expired. Change your password now. >> Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 >> WARNING: Your password has expired. >> You must change your password now and login again! >> Changing password for user tuser. >> Current Password: >> New password: >> Retype new password: >> passwd: all authentication tokens updated successfully. >> Connection to methusalix2 closed. >> $ ssh tuser at methusalix2 >> tuser at methusalix2's password: >> Permission denied, please try again. >> tuser at methusalix2's password: >> Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 >> -bash-4.1$ >> => SSH Login works (Kerberos PW is set). >> 3. Let's browse Samba: >> $ smbclient -U tuser -L methusalix2 >> Enter tuser's password: >> session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE >> >> Any ideas what's going wrong? > Uhmm seem one of the samba attributes has not been properly changed ... Yes. I realized the attribute sambaPwdLastSet was not set or wrongly set (=0). I adapted it on a few users and the problem with the NT_STATUS_PASSWORD_MUST_CHANGE went away. Still the problem is what happens when they change their password again. It looks like ldap passwd sync=yes should normally keep track of that. Any ideas how I can get that running? You also mentioned that one can use ldappasswd to get Samba to change the passwords per user. How should this be done? passwd program = /usr/bin/ldappasswd ?? > > This is IPA on RHEL6.3 ? Yes RHEL6.3 plain. > > Can you check if the use has the attribute sambaPwdMustChange set ? No not anywhere. See above (sambaPwdLastSet). > Apparently the IPA passoword plugin does not touch it. No it doesn't. I'd say it should touch sambaPwdLastSet. Shouldn't it? > > Simo. > Marc. -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From pspacek at redhat.com Fri Oct 12 11:37:37 2012 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 12 Oct 2012 13:37:37 +0200 Subject: [Freeipa-users] dyndb-ldap in standart ldap In-Reply-To: <1350035524.2220.7.camel@arthur.bashnl.local> References: <1350035524.2220.7.camel@arthur.bashnl.local> Message-ID: <50780101.6020102@redhat.com> On 10/12/2012 11:52 AM, ????? ????????? wrote: > Hi, everyone! > On site of the dyndb-ldap project > https://fedorahosted.org/bind-dyndb-ldap/ is told that for any question > I should ask here. You are on the right place, welcome! > May be it is an old question, but I didn't find anything on it. > I just want to learn how to store records for dyndb-ldap in standart > LDAP-server such as 389-ds or OpenLDAP. If I am fool and couldn't find > it, please, show me where I can learn it (google couldn'r help me). > Or may You can explain me it, and I could make documentation for it? Unfortunately, we don't have comprehensive documentation. If you want to give it a quick try, you can install FreeIPA. Command $ ipa-server-install --setup-dns will install FreeIPA server and configures DNS subtree in LDAP and configures /etc/named.conf appropriately. If you want to start with bind-dyndb-ldap from scratch it is a bit harder. First of all, you need to put our DNS schema to your DNS server: http://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/tree/doc/schema After schema set-up you can create a tree of objects. cn=dns,dc=test - root of DNS subtree in this example - idnsConfig object class - contains global configuration idnsname=zone.tld,cn=dns,dc=test - DNS zone "zone.tld", contains all records associated with name "zone.tld" - container for DNS names inside this zone (e.g. for a.zone.tld) - idnsZone+idnsRecord object class idnsname=a,idnsname=zone.tld,cn=dns,dc=test - DNS name "a.zone.tld" - all records for name "a.zone.tld" are attributes in this object - idnsRecord object class Attached file "example.ldif" contains DNS subtree exported from a lab machine. It shows single forward and single reverse zone with some records. I personally recommend 389 DS because it supports persistent search feature. Persistent search allows to propagate any change in LDAP immediately to the DNS server and eliminates caching problems. Also, persistent search is required for SOA serial auto incrementation feature, please see "serial_autoincrement" in README: http://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/tree/README Let me know if you want further assistance. -- Petr Spacek -------------- next part -------------- A non-text attachment was scrubbed... Name: example.ldif Type: text/x-ldif Size: 2340 bytes Desc: not available URL: From dpal at redhat.com Fri Oct 12 13:38:24 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 12 Oct 2012 09:38:24 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <5077FD09.5090402@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> Message-ID: <50781D50.90305@redhat.com> On 10/12/2012 07:20 AM, Marc Grimme wrote: > Am 11.10.2012 18:12, schrieb Simo Sorce: >> On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: >>> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: >>> No they are integrated in the Kerberos Domain of IPA but not joined to >>> the samba domain. >>>> Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? >> Yes, you should use "ldap passwd sync = only" > Ok, I set it as suggested. >>> Further testing. >>> I have a user called tuser. >>> 1. Reset the password: >>> ipaserver1 # ipa passwd tuser >>> New Password: >>> Enter New Password again to verify: >>> ------------------------------------ >>> Changed password for "tuser at CL.ATIX" >>> ------------------------------------ >>> 2. Login to another server via ssh: >>> $ ssh tuser at methusalix2 >>> tuser at methusalix2's password: >>> Password expired. Change your password now. >>> Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 >>> WARNING: Your password has expired. >>> You must change your password now and login again! >>> Changing password for user tuser. >>> Current Password: >>> New password: >>> Retype new password: >>> passwd: all authentication tokens updated successfully. >>> Connection to methusalix2 closed. >>> $ ssh tuser at methusalix2 >>> tuser at methusalix2's password: >>> Permission denied, please try again. >>> tuser at methusalix2's password: >>> Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 >>> -bash-4.1$ >>> => SSH Login works (Kerberos PW is set). >>> 3. Let's browse Samba: >>> $ smbclient -U tuser -L methusalix2 >>> Enter tuser's password: >>> session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE >>> >>> Any ideas what's going wrong? >> Uhmm seem one of the samba attributes has not been properly changed ... > Yes. I realized the attribute sambaPwdLastSet was not set or wrongly set > (=0). > I adapted it on a few users and the problem with the > NT_STATUS_PASSWORD_MUST_CHANGE went away. > Still the problem is what happens when they change their password again. > It looks like ldap passwd sync=yes should normally keep track of that. > Any ideas how I can get that running? > > You also mentioned that one can use ldappasswd to get Samba to change > the passwords per user. > How should this be done? > passwd program = /usr/bin/ldappasswd ?? > >> This is IPA on RHEL6.3 ? > Yes RHEL6.3 plain. >> Can you check if the use has the attribute sambaPwdMustChange set ? Should we open a ticket to manage this attribute? > No not anywhere. See above (sambaPwdLastSet). >> Apparently the IPA passoword plugin does not touch it. > No it doesn't. I'd say it should touch sambaPwdLastSet. Shouldn't it? >> Simo. >> > Marc. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Fri Oct 12 14:14:55 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 12 Oct 2012 10:14:55 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <50781D50.90305@redhat.com> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <50781D50.90305@redhat.com> Message-ID: <1350051295.10587.132.camel@willson.li.ssimo.org> On Fri, 2012-10-12 at 09:38 -0400, Dmitri Pal wrote: > >> Can you check if the use has the attribute sambaPwdMustChange set ? > > Should we open a ticket to manage this attribute? I thought I had a reason why it wasn't needed, but I may be wrong. I want to make sure it is/isn't but if you want to track it immediately that is ok, we can always close as invlid later if it turns out it is not needed. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Fri Oct 12 14:19:21 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 12 Oct 2012 10:19:21 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <5077FD09.5090402@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> Message-ID: <1350051561.10587.136.camel@willson.li.ssimo.org> On Fri, 2012-10-12 at 13:20 +0200, Marc Grimme wrote: > Am 11.10.2012 18:12, schrieb Simo Sorce: > > On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: > >> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: > >>> > >> No they are integrated in the Kerberos Domain of IPA but not joined to > >> the samba domain. > >>> Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? > > Yes, you should use "ldap passwd sync = only" > Ok, I set it as suggested. > > > >> Further testing. > >> I have a user called tuser. > >> 1. Reset the password: > >> ipaserver1 # ipa passwd tuser > >> New Password: > >> Enter New Password again to verify: > >> ------------------------------------ > >> Changed password for "tuser at CL.ATIX" > >> ------------------------------------ > >> 2. Login to another server via ssh: > >> $ ssh tuser at methusalix2 > >> tuser at methusalix2's password: > >> Password expired. Change your password now. > >> Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 > >> WARNING: Your password has expired. > >> You must change your password now and login again! > >> Changing password for user tuser. > >> Current Password: > >> New password: > >> Retype new password: > >> passwd: all authentication tokens updated successfully. > >> Connection to methusalix2 closed. > >> $ ssh tuser at methusalix2 > >> tuser at methusalix2's password: > >> Permission denied, please try again. > >> tuser at methusalix2's password: > >> Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 > >> -bash-4.1$ > >> => SSH Login works (Kerberos PW is set). > >> 3. Let's browse Samba: > >> $ smbclient -U tuser -L methusalix2 > >> Enter tuser's password: > >> session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE > >> > >> Any ideas what's going wrong? > > Uhmm seem one of the samba attributes has not been properly changed ... > Yes. I realized the attribute sambaPwdLastSet was not set or wrongly set > (=0). > I adapted it on a few users and the problem with the > NT_STATUS_PASSWORD_MUST_CHANGE went away. > Still the problem is what happens when they change their password again. > It looks like ldap passwd sync=yes should normally keep track of that. > Any ideas how I can get that running? As far as I can see our code does set sambaPwdLastset as well (exactly to avoid samba complain about must set). Can you do a test password change an dverify if we always fail to set it ? And what are the values before/after the attempt (in either case) ? > You also mentioned that one can use ldappasswd to get Samba to change > the passwords per user. > How should this be done? > passwd program = /usr/bin/ldappasswd ?? Samba use the ldappasswd control when you set ldap passwd sync = only Nothing else is required > > > > This is IPA on RHEL6.3 ? > Yes RHEL6.3 plain. > > > > Can you check if the use has the attribute sambaPwdMustChange set ? > No not anywhere. See above (sambaPwdLastSet). Ok perfect, this means it is not used (as I thought) and was deprecated. (Dmitri this means we do not need to track) > > Apparently the IPA passoword plugin does not touch it. > No it doesn't. I'd say it should touch sambaPwdLastSet. Shouldn't it? It should and we have code in the 2.2 and 3.0 branches to do it. I wonder if we have a bug in the RHEL6.3 version, if you can do the test above we can try to narrow down what's happening. Simo. -- Simo Sorce * Red Hat, Inc * New York From grimme at atix.de Fri Oct 12 14:47:11 2012 From: grimme at atix.de (Marc Grimme) Date: Fri, 12 Oct 2012 16:47:11 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350051561.10587.136.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> Message-ID: <50782D6F.5040906@atix.de> Am 12.10.2012 16:19, schrieb Simo Sorce: > On Fri, 2012-10-12 at 13:20 +0200, Marc Grimme wrote: >> Am 11.10.2012 18:12, schrieb Simo Sorce: >>> On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: >>>> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: >>>> No they are integrated in the Kerberos Domain of IPA but not joined to >>>> the samba domain. >>>>> Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? >>> Yes, you should use "ldap passwd sync = only" >> Ok, I set it as suggested. >>>> Further testing. >>>> I have a user called tuser. >>>> 1. Reset the password: >>>> ipaserver1 # ipa passwd tuser >>>> New Password: >>>> Enter New Password again to verify: >>>> ------------------------------------ >>>> Changed password for "tuser at CL.ATIX" >>>> ------------------------------------ >>>> 2. Login to another server via ssh: >>>> $ ssh tuser at methusalix2 >>>> tuser at methusalix2's password: >>>> Password expired. Change your password now. >>>> Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 >>>> WARNING: Your password has expired. >>>> You must change your password now and login again! >>>> Changing password for user tuser. >>>> Current Password: >>>> New password: >>>> Retype new password: >>>> passwd: all authentication tokens updated successfully. >>>> Connection to methusalix2 closed. >>>> $ ssh tuser at methusalix2 >>>> tuser at methusalix2's password: >>>> Permission denied, please try again. >>>> tuser at methusalix2's password: >>>> Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 >>>> -bash-4.1$ >>>> => SSH Login works (Kerberos PW is set). >>>> 3. Let's browse Samba: >>>> $ smbclient -U tuser -L methusalix2 >>>> Enter tuser's password: >>>> session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE >>>> >>>> Any ideas what's going wrong? >>> Uhmm seem one of the samba attributes has not been properly changed ... >> Yes. I realized the attribute sambaPwdLastSet was not set or wrongly set >> (=0). >> I adapted it on a few users and the problem with the >> NT_STATUS_PASSWORD_MUST_CHANGE went away. >> Still the problem is what happens when they change their password again. >> It looks like ldap passwd sync=yes should normally keep track of that. >> Any ideas how I can get that running? > As far as I can see our code does set sambaPwdLastset as well (exactly > to avoid samba complain about must set). > > Can you do a test password change an dverify if we always fail to set > it ? And what are the values before/after the attempt (in either case) ? After me switching to ldap passwd sync = only I cannot see it changing the values if already set. But for new users it might not be set. As I have some without these attributes set. If I create a new user (say tuser2) as follows: # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 ------------------- Added user "tuser2" ------------------- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tuser2 at CL.ATIX UID: 473000074 GID: 473000074 Password: False Kerberos keys available: False # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaPwdMustChange dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix That attribute is not set. Then I'll set a temporary password: # ipa passwd tuser2 New Password: Enter New Password again to verify: ------------------------------------- Changed password for "tuser2 at CL.ATIX" ------------------------------------- I'll change the temporary password: $ ssh tuser2 at methusalix2 tuser2 at methusalix2's password: Password expired. Change your password now. WARNING: Your password has expired. You must change your password now and login again! Changing password for user tuser2. Current Password: New password: Retype new password: passwd: all authentication tokens updated successfully. Connection to methusalix2 closed. I can login via ssh: $ ssh tuser2 at methusalix2 tuser2 at methusalix2's password: Last login: Fri Oct 12 16:34:26 2012 from mobilix-20.gallien.atix And the ldap attribute is still not set: # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaPwdMustChange dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix So the access via samba fails: $ smbclient -U tuser2 -L methusalix2 -D ATIX2 Enter tuser2's password: session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE When I fix the attribute manually: # bash ~/add-sambapwdlastset2user.sh tuser2 Wrong value. Modifying to proper one.. SASL/GSSAPI authentication started SASL username: admin at CL.ATIX SASL SSF: 56 SASL data security layer installed. modifying entry "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" I can access samba as follows: smbclient -U tuser2 -L methusalix2 -D ATIX2 Enter tuser2's password: Domain=[ATIX2] OS=[Unix] Server=[Samba 3.5.10-125.el6] Sharename Type Comment .. So the initial setup seems to be the problem, right? Besides: It also looks like the Distributed Numerica Assignment Plugin seems to be not working. As I always have to manually specify the SID of the user: ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b "cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" -D "cn=Directory Manager" -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 Thanks Marc. > >> You also mentioned that one can use ldappasswd to get Samba to change >> the passwords per user. >> How should this be done? >> passwd program = /usr/bin/ldappasswd ?? > Samba use the ldappasswd control when you set ldap passwd sync = only > Nothing else is required Ok. That's my understanding as well. > >>> This is IPA on RHEL6.3 ? >> Yes RHEL6.3 plain. >>> Can you check if the use has the attribute sambaPwdMustChange set ? >> No not anywhere. See above (sambaPwdLastSet). > Ok perfect, this means it is not used (as I thought) and was deprecated. > (Dmitri this means we do not need to track) > >>> Apparently the IPA passoword plugin does not touch it. >> No it doesn't. I'd say it should touch sambaPwdLastSet. Shouldn't it? > It should and we have code in the 2.2 and 3.0 branches to do it. > I wonder if we have a bug in the RHEL6.3 version, if you can do the test > above we can try to narrow down what's happening. > > Simo. > -- Marc Grimme Tel: +49 (0)89 452 35 38-140 Fax: +49 (0)89 452 35 38-290 E-Mail: grimme at atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From rcritten at redhat.com Fri Oct 12 18:06:54 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 14:06:54 -0400 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release Message-ID: <50785C3E.8070202@redhat.com> The FreeIPA team is proud to announce version FreeIPA v3.0.0. It can be downloaded from http://www.freeipa.org/Downloads. A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works well in Fedora 17 but we will not be providing a build in the Fedora 17 following Fedora's policy of not moving forward with releases. There is a known issue installing a replica with a dogtag CA in Fedora 18. We are continuing to investigate. Non-CA replica installation is fine, and upgrading a replica with a CA is unaffected. FreeIPA will be participating in a Fedora 18 Test Day next Monday, October 15. For details see http://fedoraproject.org/wiki/Test_Day:2012-10-15_FreeIPA == Highlights in 3.0.0 == * Support for AD Trust * Per-domain DNS permissions * DNS persistent search enabled by default, new zones are seen immediately * New DNS resolver library * Migration improvements * The last administrator cannot be removed or disabled * Forms-based password reset * Redesigned action panels in UI * Sessions for command-line users * Tool to configure automount client, ipa-client-automount * NTLM password hash is generated for existing users on first use of IPA cross-realm environment based on their Kerberos keys without requiring a password change. * Secure identifiers compatible with Active Directory are generated automatically for existing users upon set up of IPA cross-realm environment. * Use certmonger to renew CA subsystem certificates * Support for DNS zone transfers to non-IPA slaves * Internal change to LDAP Distinguished Name handling to be more robust * Better support for Internet Explorer 9 in the UI * Allow multiple servers on client install command-line and configuring without DNS discovery. * Cooperate with new 389-ds-base winsync POSIX plugin so that AD POSIX attribute can be synced with IPA. * Improvements to schema upgrade process. * Exclude some attributes from replication. * Notify success on add, delete and update in UI. * Set the e-mail attribute on new users by default. * SSH public key format has been changed to OpenSSH-style public keys. * Support for the Dogtag CA version 10 * New ipa-client-install option to disable OpenSSH client configuration. * Expand Referential Integrity checks on hosts, SUDO and HBAC rule referential attributes * Run the CLEANALLRUV task when deleting a replication agreement to remove replication meta-data about removed master. See the ipa-replica-manage man page for the list of new commands related to CLEANALLRUV command. * Try to prevent orphaning other servers when deleting a master. * Add missing indices for automount and principal aliases which will improve performance. * Provide a new Firefox extension for configuring the browser. Firefox 15 deprecated the interface we used in the past to set the Kerberos negotiation directives. This new extension will be used on Firefox 15 and beyond, and the older interface for older browsers. * Man page improvements * A SID can be created as the last step of ipa-adtrust-install. * Create a default fallback group for AD trust users. * Support for 389-ds-base 1.3.0. * Move CRL publish directory to IPA owned directory * Add uniqueness plugin configuration for sudorule names. * The initial IPA server with a dogtag CA is configured to generate CRLs. Subsequent masters are configured to not generate CRLs. The CRL is available on a non-generating master at http://fqdn.example.com/ipa/crl/MasterCRL.bin. == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. Please note, that the referential integrity extension requires an extended set of indexes to be configured. RPM update for an IPA server with a excessive number of hosts, SUDO or HBAC entries may require several minutes to finish. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. Upgrading from 2.2.0 is supported. Upgrading from previous versions is not supported and has not been tested. An enrolled client does not need the new packages installed unless you want to re-enroll it. SSH keys for already installed clients are not uploaded, you will have to re-enroll the client or manually upload the keys. == Feedback == Please provide comments, bugs and other feedback via the freeipa-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 3.0.0 rc2 == Alexander Bokovoy (7): * support multi-line error messages in exceptions * Handle NotFound exception when establishing trust * Fix wrong RID for Domain Admins in the examples of trust commands * Add cifs principal to S4U2Proxy targets only when running ipa-adtrust-install * Make sure samba{,4}-winbind-krb5-locator package is not used with trusts * Add instructions support to PublicError * Use PublicError instructions support for trust-add case when domain is not found Jan Cholasta (1): * Do not show full SSH public keys in command output by default. Martin Kosek (3): * Minor fixes for default SMB group * Move CRL publish directory to IPA owned directory * Fix CA CRL migration crash in ipa-upgradeconfig Petr Viktorin (4): * ipa-upgradeconfig: Remove the upgrade_httpd_selinux function * replica-install: Don't copy Firefox config extension files if they're not in the replica file * Create Firefox extension on upgrade and replica-install * Pull translation files from Transifex Petr Vobornik (1): * Add mime type to httpd ipa.conf for xpi exetension Rob Crittenden (6): * Add uniqueness plugin configuration for sudorule cn * Set renewal time for the CA audit certificate to 720 days. * Fix CS replication management. * Configure the initial CA as the CRL generator. * Explicitly disable betxn plugins for the time being. * Become IPA 3.0.0 Simo Sorce (2): * Fix trust attributes for ipa trust-add * Use stricter requirement for krb5-server Sumit Bose (2): * ipa-adtrust-install: create fallback group with ldif file * ipadb: reload trust information if domain is not known Tomas Babej (1): * Notify user about necessary ports in ipa-client-install From rcritten at redhat.com Fri Oct 12 19:12:44 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 12 Oct 2012 15:12:44 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <50782D6F.5040906@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> Message-ID: <50786BAC.2030903@redhat.com> Marc Grimme wrote: > Am 12.10.2012 16:19, schrieb Simo Sorce: >> On Fri, 2012-10-12 at 13:20 +0200, Marc Grimme wrote: >>> Am 11.10.2012 18:12, schrieb Simo Sorce: >>>> On Thu, 2012-10-11 at 17:48 +0200, Marc Grimme wrote: >>>>> On Do 11 Okt 2012 14:37:57 CEST, Simo Sorce wrote: >>>>> No they are integrated in the Kerberos Domain of IPA but not joined to >>>>> the samba domain. >>>>>> Ok. Sorry I'm using ldap passwd sync=Yes Is that wrong? >>>> Yes, you should use "ldap passwd sync = only" >>> Ok, I set it as suggested. >>>>> Further testing. >>>>> I have a user called tuser. >>>>> 1. Reset the password: >>>>> ipaserver1 # ipa passwd tuser >>>>> New Password: >>>>> Enter New Password again to verify: >>>>> ------------------------------------ >>>>> Changed password for "tuser at CL.ATIX" >>>>> ------------------------------------ >>>>> 2. Login to another server via ssh: >>>>> $ ssh tuser at methusalix2 >>>>> tuser at methusalix2's password: >>>>> Password expired. Change your password now. >>>>> Last login: Thu Oct 11 17:41:47 2012 from 10.8.0.138 >>>>> WARNING: Your password has expired. >>>>> You must change your password now and login again! >>>>> Changing password for user tuser. >>>>> Current Password: >>>>> New password: >>>>> Retype new password: >>>>> passwd: all authentication tokens updated successfully. >>>>> Connection to methusalix2 closed. >>>>> $ ssh tuser at methusalix2 >>>>> tuser at methusalix2's password: >>>>> Permission denied, please try again. >>>>> tuser at methusalix2's password: >>>>> Last login: Thu Oct 11 17:42:17 2012 from 10.8.0.138 >>>>> -bash-4.1$ >>>>> => SSH Login works (Kerberos PW is set). >>>>> 3. Let's browse Samba: >>>>> $ smbclient -U tuser -L methusalix2 >>>>> Enter tuser's password: >>>>> session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE >>>>> >>>>> Any ideas what's going wrong? >>>> Uhmm seem one of the samba attributes has not been properly changed ... >>> Yes. I realized the attribute sambaPwdLastSet was not set or wrongly set >>> (=0). >>> I adapted it on a few users and the problem with the >>> NT_STATUS_PASSWORD_MUST_CHANGE went away. >>> Still the problem is what happens when they change their password again. >>> It looks like ldap passwd sync=yes should normally keep track of that. >>> Any ideas how I can get that running? >> As far as I can see our code does set sambaPwdLastset as well (exactly >> to avoid samba complain about must set). >> >> Can you do a test password change an dverify if we always fail to set >> it ? And what are the values before/after the attempt (in either case) ? > After me switching to > ldap passwd sync = only > I cannot see it changing the values if already set. > But for new users it might not be set. As I have some without these > attributes set. > If I create a new user (say tuser2) as follows: > # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 > ------------------- > Added user "tuser2" > ------------------- > User login: tuser2 > First name: Test > Last name: User2 > Full name: Test User2 > Display name: Test User2 > Initials: TU > Home directory: /home/tuser2 > GECOS field: Test User2 > Login shell: /bin/false > Kerberos principal: tuser2 at CL.ATIX > UID: 473000074 > GID: 473000074 > Password: False > Kerberos keys available: False > # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaPwdMustChange > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > > That attribute is not set. > Then I'll set a temporary password: > > # ipa passwd tuser2 > New Password: > Enter New Password again to verify: > ------------------------------------- > Changed password for "tuser2 at CL.ATIX" > ------------------------------------- > > I'll change the temporary password: > > $ ssh tuser2 at methusalix2 > tuser2 at methusalix2's password: > Password expired. Change your password now. > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user tuser2. > Current Password: > New password: > Retype new password: > passwd: all authentication tokens updated successfully. > Connection to methusalix2 closed. > > I can login via ssh: > $ ssh tuser2 at methusalix2 > tuser2 at methusalix2's password: > Last login: Fri Oct 12 16:34:26 2012 from mobilix-20.gallien.atix > > And the ldap attribute is still not set: > # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaPwdMustChange > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > > So the access via samba fails: > $ smbclient -U tuser2 -L methusalix2 -D ATIX2 > Enter tuser2's password: > session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE > > When I fix the attribute manually: > # bash ~/add-sambapwdlastset2user.sh tuser2 > Wrong value. Modifying to proper one.. > SASL/GSSAPI authentication started > SASL username: admin at CL.ATIX > SASL SSF: 56 > SASL data security layer installed. > modifying entry "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" > > I can access samba as follows: > smbclient -U tuser2 -L methusalix2 -D ATIX2 > Enter tuser2's password: > Domain=[ATIX2] OS=[Unix] Server=[Samba 3.5.10-125.el6] > > Sharename Type Comment > .. > > So the initial setup seems to be the problem, right? > > Besides: > It also looks like the Distributed Numerica Assignment Plugin seems to > be not working. As I always have to manually specify the SID of the user: > ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 > > Although my configurations looks ok, doesn't it? > # ldapsearch -LLL -b "cn=SambaSID,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config" -D "cn=Directory Manager" -x -W > Enter LDAP Password: > dn: cn=SambaSid,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-1310149461-105972258- > dnainterval: 1 > dnamagicregen: assign > dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > dnascope: dc=atix,dc=cl > cn: SambaSid > dnanextvalue: 15400 For DNA to kick in the attribute you want to set needs to have the magic regen value in it, in this case the string "assign". So when adding a new user you want to have --setattr sambaSID=assign. Or you could create a small IPA plugin to add this automatically. Incidentally, the 389-ds team recommends against using string values for the DNA magic value. rob From natxo.asenjo at gmail.com Sun Oct 14 15:16:27 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Sun, 14 Oct 2012 17:16:27 +0200 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: <50785C3E.8070202@redhat.com> References: <50785C3E.8070202@redhat.com> Message-ID: On Fri, Oct 12, 2012 at 8:06 PM, Rob Crittenden wrote: > The FreeIPA team is proud to announce version FreeIPA v3.0.0. > > It can be downloaded from http://www.freeipa.org/Downloads. > > A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works > well in Fedora 17 but we will not be providing a build in the Fedora 17 > following Fedora's policy of not moving forward with releases. Nice, thanks! Is RHEL 6.3 going to get it as well or must we wait a bit longer :-) ? -- natxo From Steven.Jones at vuw.ac.nz Sun Oct 14 19:32:24 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 14 Oct 2012 19:32:24 +0000 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: References: <50785C3E.8070202@redhat.com>, Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E7648@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I think it was/is scheduled for 6.4...which is I assume December. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Natxo Asenjo [natxo.asenjo at gmail.com] Sent: Monday, 15 October 2012 4:16 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Announcing FreeIPA v3.0.0 Release On Fri, Oct 12, 2012 at 8:06 PM, Rob Crittenden wrote: > The FreeIPA team is proud to announce version FreeIPA v3.0.0. > > It can be downloaded from http://www.freeipa.org/Downloads. > > A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works > well in Fedora 17 but we will not be providing a build in the Fedora 17 > following Fedora's policy of not moving forward with releases. Nice, thanks! Is RHEL 6.3 going to get it as well or must we wait a bit longer :-) ? -- natxo _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Sun Oct 14 21:14:01 2012 From: simo at redhat.com (Simo Sorce) Date: Sun, 14 Oct 2012 17:14:01 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <50782D6F.5040906@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> Message-ID: <1350249241.10587.183.camel@willson.li.ssimo.org> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > After me switching to > ldap passwd sync = only > I cannot see it changing the values if already set. > But for new users it might not be set. As I have some without these > attributes set. > If I create a new user (say tuser2) as follows: > # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 > ------------------- > Added user "tuser2" > ------------------- > User login: tuser2 > First name: Test > Last name: User2 > Full name: Test User2 > Display name: Test User2 > Initials: TU > Home directory: /home/tuser2 > GECOS field: Test User2 > Login shell: /bin/false > Kerberos principal: tuser2 at CL.ATIX > UID: 473000074 > GID: 473000074 > Password: False > Kerberos keys available: False > # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaPwdMustChange > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > > That attribute is not set. Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? > Then I'll set a temporary password: > > # ipa passwd tuser2 > New Password: > Enter New Password again to verify: > ------------------------------------- > Changed password for "tuser2 at CL.ATIX" > ------------------------------------- > > I'll change the temporary password: > > $ ssh tuser2 at methusalix2 > tuser2 at methusalix2's password: > Password expired. Change your password now. > WARNING: Your password has expired. > You must change your password now and login again! > Changing password for user tuser2. > Current Password: > New password: > Retype new password: > passwd: all authentication tokens updated successfully. > Connection to methusalix2 closed. > > I can login via ssh: > $ ssh tuser2 at methusalix2 > tuser2 at methusalix2's password: > Last login: Fri Oct 12 16:34:26 2012 from mobilix-20.gallien.atix > > And the ldap attribute is still not set: > # ldapsearch -LLL -x -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaPwdMustChange > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > > So the access via samba fails: > $ smbclient -U tuser2 -L methusalix2 -D ATIX2 > Enter tuser2's password: > session setup failed: NT_STATUS_PASSWORD_MUST_CHANGE > > When I fix the attribute manually: > # bash ~/add-sambapwdlastset2user.sh tuser2 > Wrong value. Modifying to proper one.. > SASL/GSSAPI authentication started > SASL username: admin at CL.ATIX > SASL SSF: 56 > SASL data security layer installed. > modifying entry "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" Which attribute are you 'fixing' ? And how ? Can you should me the specific attribute you are 'fixing' before/after the password change and before/after the 'fix' ? > I can access samba as follows: > smbclient -U tuser2 -L methusalix2 -D ATIX2 > Enter tuser2's password: > Domain=[ATIX2] OS=[Unix] Server=[Samba 3.5.10-125.el6] > > Sharename Type Comment > .. > > So the initial setup seems to be the problem, right? There seem to be an issue somewhere indeed, we need to narrow down to the exact change, then I can look in the code and see what's going on in there, as sambaPwdLastSet should be changed by the code. > Besides: > It also looks like the Distributed Numerica Assignment Plugin seems to > be not working. As I always have to manually specify the SID of the user: > ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --addattr=sambaSID=S-1-5-21-1310149461-105972258-15305 See Rob's answer for this. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Mon Oct 15 01:03:24 2012 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 14 Oct 2012 21:03:24 -0400 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E7648@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <50785C3E.8070202@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E7648@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <507B60DC.3060002@redhat.com> On 10/14/2012 03:32 PM, Steven Jones wrote: > Hi, > > I think it was/is scheduled for 6.4...which is I assume December. No. You expect a bit too soon. The cycle is about 6-7 months but you need to factor in the holiday season. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Natxo Asenjo [natxo.asenjo at gmail.com] > Sent: Monday, 15 October 2012 4:16 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Announcing FreeIPA v3.0.0 Release > > On Fri, Oct 12, 2012 at 8:06 PM, Rob Crittenden wrote: >> The FreeIPA team is proud to announce version FreeIPA v3.0.0. >> >> It can be downloaded from http://www.freeipa.org/Downloads. >> >> A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works >> well in Fedora 17 but we will not be providing a build in the Fedora 17 >> following Fedora's policy of not moving forward with releases. > Nice, thanks! > > Is RHEL 6.3 going to get it as well or must we wait a bit longer :-) ? > > -- > natxo > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Mon Oct 15 01:21:50 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 15 Oct 2012 01:21:50 +0000 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: <507B60DC.3060002@redhat.com> References: <50785C3E.8070202@redhat.com>, <833D8E48405E064EBC54C84EC6B36E40546E7648@STAWINCOX10MBX1.staff.vuw.ac.nz>, <507B60DC.3060002@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E8E9F@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Ah, that might explain an approximate date I was given on something else. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Monday, 15 October 2012 2:03 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Announcing FreeIPA v3.0.0 Release On 10/14/2012 03:32 PM, Steven Jones wrote: > Hi, > > I think it was/is scheduled for 6.4...which is I assume December. No. You expect a bit too soon. The cycle is about 6-7 months but you need to factor in the holiday season. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Natxo Asenjo [natxo.asenjo at gmail.com] > Sent: Monday, 15 October 2012 4:16 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Announcing FreeIPA v3.0.0 Release > > On Fri, Oct 12, 2012 at 8:06 PM, Rob Crittenden wrote: >> The FreeIPA team is proud to announce version FreeIPA v3.0.0. >> >> It can be downloaded from http://www.freeipa.org/Downloads. >> >> A build is on the way to updates-testing for Fedora 18. FreeIPA 3.0.0 works >> well in Fedora 17 but we will not be providing a build in the Fedora 17 >> following Fedora's policy of not moving forward with releases. > Nice, thanks! > > Is RHEL 6.3 going to get it as well or must we wait a bit longer :-) ? > > -- > natxo > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From mkosek at redhat.com Mon Oct 15 08:32:24 2012 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 15 Oct 2012 10:32:24 +0200 Subject: [Freeipa-users] Announcing FreeIPA v3.0.0 Release In-Reply-To: <50785C3E.8070202@redhat.com> References: <50785C3E.8070202@redhat.com> Message-ID: <507BCA18.3000302@redhat.com> On 10/12/2012 08:06 PM, Rob Crittenden wrote: > The FreeIPA team is proud to announce version FreeIPA v3.0.0. > > It can be downloaded from http://www.freeipa.org/Downloads. Correction: FreeIPA 3.0.0 can be downloaded from http://www.freeipa.org/page/Downloads Martin From grimme at atix.de Mon Oct 15 12:15:40 2012 From: grimme at atix.de (Marc Grimme) Date: Mon, 15 Oct 2012 14:15:40 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350249241.10587.183.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> Message-ID: <507BFE6C.2050700@atix.de> Am 14.10.2012 23:14, schrieb Simo Sorce: > On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > Right I am ok with sambaPwdMustChange not being set. That's all good. > What about sambaPwdLastSet ? Not set when a user is created new. When I change the password: sambaPwdLastSet: 0 Not working with samba! Need to apply my script (see below). BTW: when I create a user as follows: ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=assign The SambaSID is: just assign. ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" sambaSID SASL/GSSAPI authentication started SASL username: admin at CL.ATIX SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: assign Am I missing something or is this to be changed later on? > Which attribute are you 'fixing' ? > And how ? I wrote a script that basically does the following. out=$(ldapsearch -LLL -b uid=$1,cn=users,cn=accounts,dc=cl,dc=atix sambaPwdLastSet 2>/dev/null) if [ $? -ne 0 ]; then echo "Error during retreiving of sambaPwdLastSet.." exit 1 fi pwdlastset=$(echo "$out" | head -2 | tail -1 | cut -f2 -d " ") if [ -z "$pwdlastset" ]; then echo "Adding a pwdlastset time.." ldapadd < > Can you should me the specific attribute you are 'fixing' before/after > the password change and before/after the 'fix' ? see above. >> I can access samba as follows: >> smbclient -U tuser2 -L methusalix2 -D ATIX2 >> Enter tuser2's password: >> Domain=[ATIX2] OS=[Unix] Server=[Samba 3.5.10-125.el6] >> >> Sharename Type Comment >> .. >> >> So the initial setup seems to be the problem, right? > There seem to be an issue somewhere indeed, we need to narrow down to > the exact change, then I can look in the code and see what's going on in > there, as sambaPwdLastSet should be changed by the code. Hope this helps. Do you need more information? -- Marc Grimme E-Mail: grimme( at )atix.de ATIX Informationstechnologie und Consulting AG | Einsteinstrasse 10 | 85716 Unterschleissheim | www.atix.de | www.comoonics.org Registergericht: Amtsgericht Muenchen, Registernummer: HRB 168930, USt.-Id.: DE209485962 | Vorstand: Marc Grimme, Mark Hlawatschek, Thomas Merz (Vors.) | Vorsitzender des Aufsichtsrats: Dr. Martin Buss From simo at redhat.com Mon Oct 15 13:50:41 2012 From: simo at redhat.com (Simo Sorce) Date: Mon, 15 Oct 2012 09:50:41 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <507BFE6C.2050700@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> Message-ID: <1350309041.10587.190.camel@willson.li.ssimo.org> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: > Am 14.10.2012 23:14, schrieb Simo Sorce: > > On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > > Right I am ok with sambaPwdMustChange not being set. That's all good. > > What about sambaPwdLastSet ? > Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. > When I change the password: > sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. > Not working with samba! > Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired > BTW: when I create a user as follows: > ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --setattr=SambaSID=assign > The SambaSID is: just assign. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Mon Oct 15 14:03:29 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Oct 2012 10:03:29 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <507BFE6C.2050700@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> Message-ID: <507C17B1.7000309@redhat.com> Marc Grimme wrote: > Am 14.10.2012 23:14, schrieb Simo Sorce: >> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: >> Right I am ok with sambaPwdMustChange not being set. That's all good. >> What about sambaPwdLastSet ? > Not set when a user is created new. > When I change the password: > sambaPwdLastSet: 0 > Not working with samba! > Need to apply my script (see below). > > BTW: when I create a user as follows: > ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --setattr=SambaSID=assign > The SambaSID is: just assign. > ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" sambaSID > SASL/GSSAPI authentication started > SASL username: admin at CL.ATIX > SASL SSF: 56 > SASL data security layer installed. > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaSID: assign > Am I missing something or is this to be changed later on? What objectclasses is your user getting by default? Is it satisfying the DNA filter? rob > >> Which attribute are you 'fixing' ? >> And how ? > I wrote a script that basically does the following. > > out=$(ldapsearch -LLL -b uid=$1,cn=users,cn=accounts,dc=cl,dc=atix > sambaPwdLastSet 2>/dev/null) > if [ $? -ne 0 ]; then > echo "Error during retreiving of sambaPwdLastSet.." > exit 1 > fi > pwdlastset=$(echo "$out" | head -2 | tail -1 | cut -f2 -d " ") > if [ -z "$pwdlastset" ]; then > echo "Adding a pwdlastset time.." > ldapadd < dn: uid=$1,cn=users,cn=accounts,dc=cl,dc=atix > changetype: add > add: sambaPwdLastSet > sambaPwdLastSet: 1344931739 > EOF > elif [ "$pwdlastset" = "0" ]; then > echo "Wrong value. Modifying to proper one.." > ldapmodify < dn: uid=$1,cn=users,cn=accounts,dc=cl,dc=atix > changetype: modify > replace: sambaPwdLastSet > sambaPwdLastSet: 1344931739 > EOF > else > echo "Everything ok. sambaPwdLastSet: $pwdlastset" > fi > >> >> Can you should me the specific attribute you are 'fixing' before/after >> the password change and before/after the 'fix' ? > see above. >>> I can access samba as follows: >>> smbclient -U tuser2 -L methusalix2 -D ATIX2 >>> Enter tuser2's password: >>> Domain=[ATIX2] OS=[Unix] Server=[Samba 3.5.10-125.el6] >>> >>> Sharename Type Comment >>> .. >>> >>> So the initial setup seems to be the problem, right? >> There seem to be an issue somewhere indeed, we need to narrow down to >> the exact change, then I can look in the code and see what's going on in >> there, as sambaPwdLastSet should be changed by the code. > Hope this helps. > Do you need more information? > From rcritten at redhat.com Mon Oct 15 14:21:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 15 Oct 2012 10:21:08 -0400 Subject: [Freeipa-users] Test Day today Message-ID: <507C1BD4.1080604@redhat.com> We're participating in the Fedora Test Days, and today is our day! The list of tests can be found at: https://fedoraproject.org/wiki/Test_Day:2012-10-15_FreeIPA The latest Fedora 18 beta test compose is available via https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test Please test with the current freeipa, pki-ca and 389-ds-base packages in Fedora 18. The versions are freeipa-server-3.0.0-2, pki-ca-10.0.0-0.44.b1 and 389-ds-base-1.3.0-0.1.a1. thanks rob From jason.macklin at roche.com Mon Oct 15 20:34:05 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Mon, 15 Oct 2012 22:34:05 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. Message-ID: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! Thank you in advance for your assistance, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 15 20:46:20 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 15 Oct 2012 16:46:20 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: Message-ID: <507C761C.6040602@redhat.com> On 10/15/2012 04:34 PM, Macklin, Jason wrote: > > Hi, > > > > I apologize up front if this is obvious, but I'm having issues > configuring sudo privileges. > > > > I currently have an IPA server running FreeIPA 2.2 with sudo > configured for our administrators on all hosts. This works > fantastic! As soon as I attempt to configure a more specific sudo > rule it does not work. In my troubleshooting, I have noticed that > from the same host my admin level privileges work, but with another > user account setup to just run one command, it fails. I have turned > on sudo debugging and the only thing I can find that looks out of > sorts is the following: > > > > sudo: host_matches=0 > > > > As soon as I move the user account that is failing into the admin > group it starts to work. > > > > I have attempted every iteration of sudo configuration on the server > that I can think of. I have setup HBAC and given that a shot as > well. At this point I'm completely stumped and would appreciate any > help that I can get! > What does sudo test return? Does it return the expected results? Can you be more specific about the rule you have? Based on the description you have a rule that points to a specific user. If this user is referred to in the rule explicitly sudo does not work properly but if you move user to a group that is referenced by the rule then the rule works as expected. Is this correct description of the problem? I assume that you are turning off allow_all rule that allows anyone to do anything by default, right? > > > Thank you in advance for your assistance, > > Jason > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Oct 15 21:14:05 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 15 Oct 2012 21:14:05 +0000 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E93DF@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, my 2 cents, 2 possibilities, 1) There should I think be a HBAC rule and a sudo rule pair, I think you need both. For the HBAC rule with limited permissions you need the sudo privaledge and access say ssh and /or login, so at least 2, so when you say "1" it might be that? I dont know how you are getting access, it sounds possible. 2) or you have the bug I have it looks possible as well, Are you putting the host into a host group and using that host group in the sudo rule? There is a bug that stops that working, so in the sudo rule delete the host group and add the server server/host itself and see if that works. If so you have the bug, I find deleting the HBAC and sudo rules and starting again from scratch sometimes works, sometimes doesnt. I have 30~50% of my sudo rules with individial hosts and not groups because of this. If your problem is like mine, and you have RH support on RHEL? then raise a case, my one is #6963677 so I'd ask for it to be linked but its been open since August. :/ regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Macklin, Jason [jason.macklin at roche.com] Sent: Tuesday, 16 October 2012 9:34 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. Hi, I apologize up front if this is obvious, but I?m having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I?m completely stumped and would appreciate any help that I can get! Thank you in advance for your assistance, Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Oct 15 21:58:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 15 Oct 2012 17:58:11 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507C761C.6040602@redhat.com> References: <507C761C.6040602@redhat.com> Message-ID: <507C86F3.8020603@redhat.com> On 10/15/2012 04:46 PM, Dmitri Pal wrote: > On 10/15/2012 04:34 PM, Macklin, Jason wrote: >> >> Hi, >> >> >> >> I apologize up front if this is obvious, but I'm having issues >> configuring sudo privileges. >> >> >> >> I currently have an IPA server running FreeIPA 2.2 with sudo >> configured for our administrators on all hosts. This works >> fantastic! As soon as I attempt to configure a more specific sudo >> rule it does not work. In my troubleshooting, I have noticed that >> from the same host my admin level privileges work, but with another >> user account setup to just run one command, it fails. I have turned >> on sudo debugging and the only thing I can find that looks out of >> sorts is the following: >> >> >> >> sudo: host_matches=0 >> >> >> >> As soon as I move the user account that is failing into the admin >> group it starts to work. >> >> >> >> I have attempted every iteration of sudo configuration on the server >> that I can think of. I have setup HBAC and given that a shot as >> well. At this point I'm completely stumped and would appreciate any >> help that I can get! >> > > What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. >> >> >> Thank you in advance for your assistance, >> >> Jason >> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From antti.peltonen at iki.fi Tue Oct 16 06:53:12 2012 From: antti.peltonen at iki.fi (Antti Peltonen) Date: Tue, 16 Oct 2012 09:53:12 +0300 Subject: [Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit "problem" Message-ID: Hi all, Just playing around with my setup that consists of two FreeIPA domain controllers on CentOS6.3 so the version of FreeIPA in use there is 2.2.0 So now after setting up my test laptop with Fedora 17 I proceeded to do an client installation and it seems freeipa-client version on F17 is also 2.2.0 but such things as sudo and sssd are much more recent than on CentOS. This caused few grey hairs until I got the sudo configuration to work by manipulating sssd.conf. Now that my user provisioned in FreeIPA domain can logon to my laptop, use sudo etc to install software I noticed a one little issue with policykit + packagekit combination. When through X I try to install an RPM package or do anything that requires admin rights it keeps asking for the root users password and not my sudo enabled FreeIPA users. If I have understood correctly packagekit advertises its request for admin rights through dbus to policykit which reads its policy files for matching description about the request. In this case the file seems to be: /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy In this policy file there is a lot of stuff which at this point makes no sense to me at all except that I guess that the lines: auth_admin describe that policykit should require user to enter an administrative level users password. Now on basic F17 installation where after first boot you create your first normal user account and give it an password there is an checkbox for "Administrator" or something similar which seems to add this user to be created in "wheel" and "adm" posix groups. When policykit requires an administrative users password it asks for this local users password if it is member of those groups (I guess) and if not it asks for the root users password. However when I add my FreeIPA user to the adm and wheel groups (silly since my sudo rules in FreeIPA give me already a full sudo rights) policykit does not seem to make a sense out of this situation and keep asking for the root users password. Now after all this bad english and a load of factual errors the actual question is: What needs to be configured and how to make FreeIPA provisioned user to be "local administrator" in policykits mind? If this is at all possible in current stage of development... p.s. I use an PackageKit here as an example target for the PolicyKit but I guess that anything to do with process rights elevation through PolicyKit is affected - not just the PackageKit application. -- Antti Peltonen | Homo sapiens | planet Earth email antti.peltonen at iki.fi irc BCOW @ IRCNet | Twitter @BrainCOW "Ars longa, vita previs." -------------- next part -------------- An HTML attachment was scrubbed... URL: From grimme at atix.de Tue Oct 16 08:06:38 2012 From: grimme at atix.de (Marc Grimme) Date: Tue, 16 Oct 2012 10:06:38 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350309041.10587.190.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> Message-ID: <507D158E.7000305@atix.de> Am 15.10.2012 15:50, schrieb Simo Sorce: > On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: >> Am 14.10.2012 23:14, schrieb Simo Sorce: >>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: >>> Right I am ok with sambaPwdMustChange not being set. That's all good. >>> What about sambaPwdLastSet ? >> Not set when a user is created new. > It should be set when you give the user a password as long at the > sambaSamAccount objectclass is added to the user. > >> When I change the password: >> sambaPwdLastSet: 0 > If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. > >> Not working with samba! >> Need to apply my script (see below). > Let me ask one thing, are you changing the password as a user ? > Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. > > If the latter this applies: > http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. > > I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign > > > Simo. > # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign ------------------- Added user "tuser2" ------------------- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tuser2 at CL.ATIX UID: 473000078 GID: 473000078 Password: False Kerberos keys available: False # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" sambaSID SASL/GSSAPI authentication started SASL username: admin at CL.ATIX SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" objectClass SASL/GSSAPI authentication started SASL username: admin at CL.ATIX SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Marc. -- Marc Grimme E-Mail: grimme( at )atix.de From simo at redhat.com Tue Oct 16 12:21:25 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Oct 2012 08:21:25 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <507D158E.7000305@atix.de> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> Message-ID: <1350390085.10587.195.camel@willson.li.ssimo.org> On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: > Am 15.10.2012 15:50, schrieb Simo Sorce: > > On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: > >> Am 14.10.2012 23:14, schrieb Simo Sorce: > >>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > >>> Right I am ok with sambaPwdMustChange not being set. That's all good. > >>> What about sambaPwdLastSet ? > >> Not set when a user is created new. > > It should be set when you give the user a password as long at the > > sambaSamAccount objectclass is added to the user. > > > >> When I change the password: > >> sambaPwdLastSet: 0 > > If this is when you set the password as an admin, it is expected. > Ok, understood. But it should change when the user resets his/her > password, right? > And that is not happening. > When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? > >> Not working with samba! > >> Need to apply my script (see below). > > Let me ask one thing, are you changing the password as a user ? > > Or have you tested only setting the password as admin ? > I set the initial password as admin. > Then the user logs in to a server (sssd, ssh, ipa-member) and is > requested to change his/her password. This works but the sambaPwdLastSet > stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? > > If the latter this applies: > > http://www.freeipa.org/page/NewPasswordsExpired > Checked it. But that was my understanding nevertheless. > > > > I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign > > > > > > Simo. > > > # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign > ------------------- > Added user "tuser2" > ------------------- > User login: tuser2 > First name: Test > Last name: User2 > Full name: Test User2 > Display name: Test User2 > Initials: TU > Home directory: /home/tuser2 > GECOS field: Test User2 > Login shell: /bin/false > Kerberos principal: tuser2 at CL.ATIX > UID: 473000078 > GID: 473000078 > Password: False > Kerberos keys available: False > # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" > sambaSID > SASL/GSSAPI authentication started > SASL username: admin at CL.ATIX > SASL SSF: 56 > SASL data security layer installed. > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > sambaSID: S-1-5-21-xx-xx-xx-assign > > The following objectclasses are being set when creating a new user: > # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" > objectClass > SASL/GSSAPI authentication started > SASL username: admin at CL.ATIX > SASL SSF: 56 > SASL data security layer installed. > dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: sambaSAMAccount > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > objectClass: mepOriginEntry > > Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Oct 16 12:28:18 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Oct 2012 08:28:18 -0400 Subject: [Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit "problem" In-Reply-To: References: Message-ID: <1350390498.10587.197.camel@willson.li.ssimo.org> On Tue, 2012-10-16 at 09:53 +0300, Antti Peltonen wrote: > Hi all, > > > Just playing around with my setup that consists of two FreeIPA domain > controllers on CentOS6.3 so the version of FreeIPA in use there is > 2.2.0 > > > So now after setting up my test laptop with Fedora 17 I proceeded to > do an client installation and it seems freeipa-client version on F17 > is also 2.2.0 but such things as sudo and sssd are much more recent > than on CentOS. This caused few grey hairs until I got the sudo > configuration to work by manipulating sssd.conf. > > > Now that my user provisioned in FreeIPA domain can logon to my laptop, > use sudo etc to install software I noticed a one little issue with > policykit + packagekit combination. When through X I try to install an > RPM package or do anything that requires admin rights it keeps asking > for the root users password and not my sudo enabled FreeIPA users. > > > If I have understood correctly packagekit advertises its request for > admin rights through dbus to policykit which reads its policy files > for matching description about the request. In this case the file > seems to > be: /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy > > > In this policy file there is a lot of stuff which at this point makes > no sense to me at all except that I guess that the > lines: auth_admin describe that policykit > should require user to enter an administrative level users password. > Now on basic F17 installation where after first boot you create your > first normal user account and give it an password there is an checkbox > for "Administrator" or something similar which seems to add this user > to be created in "wheel" and "adm" posix groups. When policykit > requires an administrative users password it asks for this local users > password if it is member of those groups (I guess) and if not it asks > for the root users password. > > > However when I add my FreeIPA user to the adm and wheel groups (silly > since my sudo rules in FreeIPA give me already a full sudo rights) > policykit does not seem to make a sense out of this situation and keep > asking for the root users password. Have you logged out and logged back in after you have done these changes ? Changes to group membership do not take effect until the user logs out and logs back in. > > Now after all this bad english and a load of factual errors the actual > question is: What needs to be configured and how to make FreeIPA > provisioned user to be "local administrator" in policykits mind? If > this is at all possible in current stage of development... It should make no difference where the user comes from, if it does it would be most likely a policykit bug/limitation/'feature' > > p.s. I use an PackageKit here as an example target for the PolicyKit > but I guess that anything to do with process rights elevation through > PolicyKit is affected - not just the PackageKit application. Understood, have you asked on policykit related mailing lists as well by chance ? Simo. -- Simo Sorce * Red Hat, Inc * New York From jason.macklin at roche.com Tue Oct 16 14:05:38 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Tue, 16 Oct 2012 10:05:38 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507C86F3.8020603@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> Message-ID: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Oct 16 14:32:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 10:32:32 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> Message-ID: <507D7000.8010300@redhat.com> On 10/16/2012 10:05 AM, Macklin, Jason wrote: > > When I become the user in question I see the following in the sssd log. > > > > [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC > rule [test] > > > > I think this is a sudo problem before anything else. For a user in > which sudo works, host_matches = 1 always returns when debugging is > on. For a user that does not work host_matches always equals 0 (zero). > > > Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. > I am open to troubleshooting the ldap configuration as I am not > convinced that it is referencing the host properly. I enroll the > clients using FQDN, but noticed that initially, domainname and > nisdomainname qould return (none). Fixing these to show the correct > domain did not change the behavior of the nodes though. > > > > Thanks again! > > > > Jason > > > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 15, 2012 5:58 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/15/2012 04:46 PM, Dmitri Pal wrote: > > On 10/15/2012 04:34 PM, Macklin, Jason wrote: > > Hi, > > > > I apologize up front if this is obvious, but I'm having issues > configuring sudo privileges. > > > > I currently have an IPA server running FreeIPA 2.2 with sudo > configured for our administrators on all hosts. This works > fantastic! As soon as I attempt to configure a more specific sudo > rule it does not work. In my troubleshooting, I have noticed that > from the same host my admin level privileges work, but with another > user account setup to just run one command, it fails. I have turned > on sudo debugging and the only thing I can find that looks out of > sorts is the following: > > > > sudo: host_matches=0 > > > > As soon as I move the user account that is failing into the admin > group it starts to work. > > > > I have attempted every iteration of sudo configuration on the server > that I can think of. I have setup HBAC and given that a shot as > well. At this point I'm completely stumped and would appreciate any > help that I can get! > > > What does sudo test return? > > > Yes I meant HBAC. I might confused you and myself so let us start over. > > First we need to make sure that the authentication happens correctly > so if HBAC is set to allow you should see in the SSSD log that access > is granted. That will limit the problem to just SUDO. If you have the > allow_all HBAC rule and no other rules then we can probably skip this > step and move on to trying to solve the actual SUDO part. > > So with SUDO one of the known issues is the long vs short hostname. Do > you by any chance use a short host name for that host? > If names are FQDN the next step would be to use ldapsearch from the > client and see what LDAP entries the server would return. > > > > > Thank you in advance for your assistance, > > Jason > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.macklin at roche.com Tue Oct 16 15:09:10 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Tue, 16 Oct 2012 11:09:10 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507D7000.8010300@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> Message-ID: Dmitri, I will give you everything I've got. If I can provide something else, let me know! Working User: Sudo debug output: [jmacklin at dbduwdu062 log]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 [sudo] password for jmacklin: Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL /var/log/secure output: Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list Non-working user: Sudo debug output: [asteinfeld at dbduwdu062 ~]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062 /var/log/secure output: Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list Cheers. Jason From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 16, 2012 10:33 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 10:05 AM, Macklin, Jason wrote: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Oct 16 15:22:02 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 11:22:02 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> Message-ID: <507D7B9A.9070909@redhat.com> On 10/16/2012 11:09 AM, Macklin, Jason wrote: > > Dmitri, > > > > I will give you everything I've got. If I can provide something else, > let me know! > > > > *Working User:* > > > > *Sudo debug output:* > > > > [jmacklin at dbduwdu062 log]$ sudo -l > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com > > sudo: user_matches=1 > > sudo: host_matches=1 > > sudo: sudo_ldap_lookup(52)=0x82 > > [sudo] password for jmacklin: > > Matching Defaults entries for jmacklin on this host: > > requiretty, !visiblepw, always_set_home, env_reset, > env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", > env_keep+="MAIL PS1 > > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", > env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", > env_keep+="LC_MONETARY > > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME > LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > > > sudo: ldap search > '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' > > sudo: ldap search 'sudoUser=+*' > > User jmacklin may run the following commands on this host: > > (root) ALL > > > > */var/log/secure output:* > > > > Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication > failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin > rhost= user=jmacklin > > Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication > success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin > rhost= user=jmacklin > > Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; > USER=root ; COMMAND=list > > > > *Non-working user:* > > * * > > *Sudo debug output:* > > * * > > [asteinfeld at dbduwdu062 ~]$ sudo -l > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com > > sudo: user_matches=1 > > sudo: host_matches=0 > > sudo: sudo_ldap_lookup(52)=0x84 > > [sudo] password for asteinfeld: > > Sorry, user asteinfeld may not run sudo on dbduwdu062 > > > > */var/log/secure output:* > > * * > > Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication > failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 > ruser=asteinfeld rhost= user=asteinfeld > > Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication > success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 > ruser=asteinfeld rhost= user=asteinfeld > > Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; > TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list > > > > Cheers. > > Jason > Please set sudoers_debug 2 http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/ > > > > > > > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Tuesday, October 16, 2012 10:33 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/16/2012 10:05 AM, Macklin, Jason wrote: > > When I become the user in question I see the following in the sssd log. > > > > [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC > rule [test] > > > > I think this is a sudo problem before anything else. For a user in > which sudo works, host_matches = 1 always returns when debugging is > on. For a user that does not work host_matches always equals 0 (zero). > > > > > Is there any way to see a more detailed debug log from sudo then? It > should show what it is looking for and what it is getting back from > the server. > > > I am open to troubleshooting the ldap configuration as I am not > convinced that it is referencing the host properly. I enroll the > clients using FQDN, but noticed that initially, domainname and > nisdomainname qould return (none). Fixing these to show the correct > domain did not change the behavior of the nodes though. > > > > Thanks again! > > > > Jason > > > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 15, 2012 5:58 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/15/2012 04:46 PM, Dmitri Pal wrote: > > On 10/15/2012 04:34 PM, Macklin, Jason wrote: > > Hi, > > > > I apologize up front if this is obvious, but I'm having issues > configuring sudo privileges. > > > > I currently have an IPA server running FreeIPA 2.2 with sudo > configured for our administrators on all hosts. This works > fantastic! As soon as I attempt to configure a more specific sudo > rule it does not work. In my troubleshooting, I have noticed that > from the same host my admin level privileges work, but with another > user account setup to just run one command, it fails. I have turned > on sudo debugging and the only thing I can find that looks out of > sorts is the following: > > > > sudo: host_matches=0 > > > > As soon as I move the user account that is failing into the admin > group it starts to work. > > > > I have attempted every iteration of sudo configuration on the server > that I can think of. I have setup HBAC and given that a shot as > well. At this point I'm completely stumped and would appreciate any > help that I can get! > > > What does sudo test return? > > > Yes I meant HBAC. I might confused you and myself so let us start over. > > First we need to make sure that the authentication happens correctly > so if HBAC is set to allow you should see in the SSSD log that access > is granted. That will limit the problem to just SUDO. If you have the > allow_all HBAC rule and no other rules then we can probably skip this > step and move on to trying to solve the actual SUDO part. > > So with SUDO one of the known issues is the long vs short hostname. Do > you by any chance use a short host name for that host? > If names are FQDN the next step would be to use ldapsearch from the > client and see what LDAP entries the server would return. > > > > > > Thank you in advance for your assistance, > > Jason > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.macklin at roche.com Tue Oct 16 15:30:52 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Tue, 16 Oct 2012 11:30:52 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507D7B9A.9070909@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> Message-ID: Working user: [jmacklin at dbduwdu062 log]$ sudo -l LDAP Config Summary =================== uri ldap://dbduvdu145.dbr.roche.com ldap_version 3 sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com bindpw Roche454 bind_timelimit 5000 timelimit 15 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: ldap sudoHost 'ALL' ... MATCH! sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap sudoHost 'ALL' ... MATCH! sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL Non-working user: Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.some.domain.com LDAP Config Summary =================== uri ldap://dbduvdu145.dbr.roche.com ldap_version 3 sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com bindpw Roche454 bind_timelimit 5000 timelimit 15 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062. Cheers, Jason From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 16, 2012 11:22 AM To: Macklin, Jason {DASB~Branford} Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 11:09 AM, Macklin, Jason wrote: Dmitri, I will give you everything I've got. If I can provide something else, let me know! Working User: Sudo debug output: [jmacklin at dbduwdu062 log]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 [sudo] password for jmacklin: Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL /var/log/secure output: Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list Non-working user: Sudo debug output: [asteinfeld at dbduwdu062 ~]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062 /var/log/secure output: Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list Cheers. Jason Please set sudoers_debug 2 http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/ From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 16, 2012 10:33 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 10:05 AM, Macklin, Jason wrote: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I'm having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I'm completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Oct 16 16:09:50 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 12:09:50 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> Message-ID: <507D86CE.8070306@redhat.com> On 10/16/2012 11:30 AM, Macklin, Jason wrote: > > *Working user:* > > * * > > [jmacklin at dbduwdu062 log]$ sudo -l > > LDAP Config Summary > > =================== > > uri ldap://dbduvdu145.dbr.roche.com > > ldap_version 3 > > sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com > > bindpw Roche454 > > bind_timelimit 5000 > > timelimit 15 > > ssl start_tls > > tls_checkpeer (yes) > > tls_cacertfile /etc/ipa/ca.crt > > =================== > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com > > sudo: ldap sudoHost 'ALL' ... MATCH! > > sudo: user_matches=1 > > sudo: host_matches=1 > > sudo: sudo_ldap_lookup(52)=0x82 > > Matching Defaults entries for jmacklin on this host: > > requiretty, !visiblepw, always_set_home, env_reset, > env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", > env_keep+="MAIL PS1 > > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", > env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", > env_keep+="LC_MONETARY > > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME > LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > > > sudo: ldap search > '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' > > sudo: ldap sudoHost 'ALL' ... MATCH! > > sudo: ldap search 'sudoUser=+*' > > User jmacklin may run the following commands on this host: > > (root) ALL > > > > *Non-working user:* > > * * > > * Rule name: test4* > > * Enabled: TRUE* > > * Command category: all* > > * Users: asteinfeld* > > * Hosts: dbduwdu062.some.domain.com* > > > > LDAP Config Summary > > =================== > > uri ldap://dbduvdu145.dbr.roche.com > > ldap_version 3 > > sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com > > bindpw Roche454 > > bind_timelimit 5000 > > timelimit 15 > > ssl start_tls > > tls_checkpeer (yes) > > tls_cacertfile /etc/ipa/ca.crt > > =================== > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com > > sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not > So this is the name the sudo client tries to match and it does not seem to find any hosts. Now we need to look at the ou=SUDOers,dc=dbr,dc=roche,dc=com with ldapsearch and see the SUDO rules that are exposed by the server and match them visually to the current host. > sudo: user_matches=1 > > sudo: host_matches=0 > > sudo: sudo_ldap_lookup(52)=0x84 > > [sudo] password for asteinfeld: > > Sorry, user asteinfeld may not run sudo on dbduwdu062. > > > > Cheers, > > Jason > > *From:*Dmitri Pal [mailto:dpal at redhat.com] > *Sent:* Tuesday, October 16, 2012 11:22 AM > *To:* Macklin, Jason {DASB~Branford} > *Cc:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/16/2012 11:09 AM, Macklin, Jason wrote: > > Dmitri, > > > > I will give you everything I've got. If I can provide something else, > let me know! > > > > *Working User:* > > > > *Sudo debug output:* > > > > [jmacklin at dbduwdu062 log]$ sudo -l > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com > > sudo: user_matches=1 > > sudo: host_matches=1 > > sudo: sudo_ldap_lookup(52)=0x82 > > [sudo] password for jmacklin: > > Matching Defaults entries for jmacklin on this host: > > requiretty, !visiblepw, always_set_home, env_reset, > env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", > env_keep+="MAIL PS1 > > PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", > env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", > env_keep+="LC_MONETARY > > LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME > LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", > > secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin > > > > sudo: ldap search > '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' > > sudo: ldap search 'sudoUser=+*' > > User jmacklin may run the following commands on this host: > > (root) ALL > > > > */var/log/secure output:* > > > > Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication > failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin > rhost= user=jmacklin > > Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication > success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin > rhost= user=jmacklin > > Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; > USER=root ; COMMAND=list > > > > *Non-working user:* > > * * > > *Sudo debug output:* > > * * > > [asteinfeld at dbduwdu062 ~]$ sudo -l > > sudo: ldap_set_option: debug -> 0 > > sudo: ldap_set_option: tls_checkpeer -> 1 > > sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt > > sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt > > sudo: ldap_set_option: ldap_version -> 3 > > sudo: ldap_set_option: timelimit -> 15 > > sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) > > sudo: ldap_start_tls_s() ok > > sudo: ldap_sasl_bind_s() ok > > sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com > > sudo: user_matches=1 > > sudo: host_matches=0 > > sudo: sudo_ldap_lookup(52)=0x84 > > [sudo] password for asteinfeld: > > Sorry, user asteinfeld may not run sudo on dbduwdu062 > > > > */var/log/secure output:* > > * * > > Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication > failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 > ruser=asteinfeld rhost= user=asteinfeld > > Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication > success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 > ruser=asteinfeld rhost= user=asteinfeld > > Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; > TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list > > > > Cheers. > > Jason > > > > Please set sudoers_debug 2 > > http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/ > > > > > > > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Tuesday, October 16, 2012 10:33 AM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/16/2012 10:05 AM, Macklin, Jason wrote: > > When I become the user in question I see the following in the sssd log. > > > > [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC > rule [test] > > > > I think this is a sudo problem before anything else. For a user in > which sudo works, host_matches = 1 always returns when debugging is > on. For a user that does not work host_matches always equals 0 (zero). > > > > > Is there any way to see a more detailed debug log from sudo then? It > should show what it is looking for and what it is getting back from > the server. > > > > I am open to troubleshooting the ldap configuration as I am not > convinced that it is referencing the host properly. I enroll the > clients using FQDN, but noticed that initially, domainname and > nisdomainname qould return (none). Fixing these to show the correct > domain did not change the behavior of the nodes though. > > > > Thanks again! > > > > Jason > > > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Monday, October 15, 2012 5:58 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Sudo works for full access, but not on > a per command or host level. > > > > On 10/15/2012 04:46 PM, Dmitri Pal wrote: > > On 10/15/2012 04:34 PM, Macklin, Jason wrote: > > Hi, > > > > I apologize up front if this is obvious, but I'm having issues > configuring sudo privileges. > > > > I currently have an IPA server running FreeIPA 2.2 with sudo > configured for our administrators on all hosts. This works > fantastic! As soon as I attempt to configure a more specific sudo > rule it does not work. In my troubleshooting, I have noticed that > from the same host my admin level privileges work, but with another > user account setup to just run one command, it fails. I have turned > on sudo debugging and the only thing I can find that looks out of > sorts is the following: > > > > sudo: host_matches=0 > > > > As soon as I move the user account that is failing into the admin > group it starts to work. > > > > I have attempted every iteration of sudo configuration on the server > that I can think of. I have setup HBAC and given that a shot as > well. At this point I'm completely stumped and would appreciate any > help that I can get! > > > What does sudo test return? > > > Yes I meant HBAC. I might confused you and myself so let us start over. > > First we need to make sure that the authentication happens correctly > so if HBAC is set to allow you should see in the SSSD log that access > is granted. That will limit the problem to just SUDO. If you have the > allow_all HBAC rule and no other rules then we can probably skip this > step and move on to trying to solve the actual SUDO part. > > So with SUDO one of the known issues is the long vs short hostname. Do > you by any chance use a short host name for that host? > If names are FQDN the next step would be to use ldapsearch from the > client and see what LDAP entries the server would return. > > > > > > > Thank you in advance for your assistance, > > Jason > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio > Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Oct 16 17:05:19 2012 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 16 Oct 2012 19:05:19 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507D86CE.8070306@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> <507D86CE.8070306@redhat.com> Message-ID: <20121016170519.GO26626@hendrix.brq.redhat.com> On Tue, Oct 16, 2012 at 12:09:50PM -0400, Dmitri Pal wrote: > > sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not > > > > So this is the name the sudo client tries to match and it does not seem > to find any hosts. > Now we need to look at the ou=SUDOers,dc=dbr,dc=roche,dc=com with > ldapsearch and see the SUDO rules that are exposed by the server and > match them visually to the current host. > Can you also check if the host name on the broken host is set correctly and resolves fine? From jason.macklin at roche.com Tue Oct 16 17:57:51 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Tue, 16 Oct 2012 19:57:51 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <20121016170519.GO26626@hendrix.brq.redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> <507D86CE.8070306@redhat.com> <20121016170519.GO26626@hendrix.brq.redhat.com> Message-ID: Yes, resolution works correctly at both the host and the freeIPA server. Dmitri, I am still quite new to LDAP so I'm not sure exactly what I should be looking for when running ldapsearch. The attempts that I have made have been less then fruitful though... examples follow /usr/bin/ldapsearch -I -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"SASL/EXTERNAL authentication started ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: This sort of return occurs for either working or non-working users both! As I am new to ldap... is there a specific ldapsearch command/option I should be using? From nkinder at redhat.com Tue Oct 16 21:22:10 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 16 Oct 2012 14:22:10 -0700 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350390085.10587.195.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> <1350390085.10587.195.camel@willson.li.ssimo.org> Message-ID: <507DD002.30009@redhat.com> On 10/16/2012 05:21 AM, Simo Sorce wrote: > On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: >> Am 15.10.2012 15:50, schrieb Simo Sorce: >>> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: >>>> Am 14.10.2012 23:14, schrieb Simo Sorce: >>>>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: >>>>> Right I am ok with sambaPwdMustChange not being set. That's all good. >>>>> What about sambaPwdLastSet ? >>>> Not set when a user is created new. >>> It should be set when you give the user a password as long at the >>> sambaSamAccount objectclass is added to the user. >>> >>>> When I change the password: >>>> sambaPwdLastSet: 0 >>> If this is when you set the password as an admin, it is expected. >> Ok, understood. But it should change when the user resets his/her >> password, right? >> And that is not happening. >> When the user sets his/her password the sambaPwdLastSet stays untouched. > That's odd, how does the user change the password ? > >>>> Not working with samba! >>>> Need to apply my script (see below). >>> Let me ask one thing, are you changing the password as a user ? >>> Or have you tested only setting the password as admin ? >> I set the initial password as admin. >> Then the user logs in to a server (sssd, ssh, ipa-member) and is >> requested to change his/her password. This works but the sambaPwdLastSet >> stays untouched. > Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? > >>> If the latter this applies: >>> http://www.freeipa.org/page/NewPasswordsExpired >> Checked it. But that was my understanding nevertheless. >>> I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign >>> >>> >>> Simo. >>> >> # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false >> --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign >> ------------------- >> Added user "tuser2" >> ------------------- >> User login: tuser2 >> First name: Test >> Last name: User2 >> Full name: Test User2 >> Display name: Test User2 >> Initials: TU >> Home directory: /home/tuser2 >> GECOS field: Test User2 >> Login shell: /bin/false >> Kerberos principal: tuser2 at CL.ATIX >> UID: 473000078 >> GID: 473000078 >> Password: False >> Kerberos keys available: False >> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >> sambaSID >> SASL/GSSAPI authentication started >> SASL username: admin at CL.ATIX >> SASL SSF: 56 >> SASL data security layer installed. >> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >> sambaSID: S-1-5-21-xx-xx-xx-assign >> >> The following objectclasses are being set when creating a new user: >> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >> objectClass >> SASL/GSSAPI authentication started >> SASL username: admin at CL.ATIX >> SASL SSF: 56 >> SASL data security layer installed. >> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: sambaSAMAccount >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> objectClass: mepOriginEntry >> >> Thanks for your help > Seem like a DNA bug ... then, > > Nathan do you have any idea ? What DNA configuration is used? -NGK > From toastedpenguininfo at gmail.com Tue Oct 16 21:24:30 2012 From: toastedpenguininfo at gmail.com (Toasted Penguin) Date: Tue, 16 Oct 2012 16:24:30 -0500 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 Message-ID: I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case "sudo su -") it fails and they get the error "user is not allowed to run sudo on client-host. This incident will be reported." I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard "User not in the sudoers file...." Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command "/bin/su", created a sudo rule "Sudo to root" , added the group the user in question is a part of to the WHO-->User Groups; Added the Host Group the target client host is part of to Access This Host-->Host Groups and added the sudo command to the sudo rule via Allow-->Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Oct 16 21:40:56 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Oct 2012 17:40:56 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <507DD002.30009@redhat.com> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> <1350390085.10587.195.camel@willson.li.ssimo.org> <507DD002.30009@redhat.com> Message-ID: <1350423656.10587.201.camel@willson.li.ssimo.org> On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: > On 10/16/2012 05:21 AM, Simo Sorce wrote: > > On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: > >> Am 15.10.2012 15:50, schrieb Simo Sorce: > >>> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: > >>>> Am 14.10.2012 23:14, schrieb Simo Sorce: > >>>>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > >>>>> Right I am ok with sambaPwdMustChange not being set. That's all good. > >>>>> What about sambaPwdLastSet ? > >>>> Not set when a user is created new. > >>> It should be set when you give the user a password as long at the > >>> sambaSamAccount objectclass is added to the user. > >>> > >>>> When I change the password: > >>>> sambaPwdLastSet: 0 > >>> If this is when you set the password as an admin, it is expected. > >> Ok, understood. But it should change when the user resets his/her > >> password, right? > >> And that is not happening. > >> When the user sets his/her password the sambaPwdLastSet stays untouched. > > That's odd, how does the user change the password ? > > > >>>> Not working with samba! > >>>> Need to apply my script (see below). > >>> Let me ask one thing, are you changing the password as a user ? > >>> Or have you tested only setting the password as admin ? > >> I set the initial password as admin. > >> Then the user logs in to a server (sssd, ssh, ipa-member) and is > >> requested to change his/her password. This works but the sambaPwdLastSet > >> stays untouched. > > Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? > > > >>> If the latter this applies: > >>> http://www.freeipa.org/page/NewPasswordsExpired > >> Checked it. But that was my understanding nevertheless. > >>> I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign > >>> > >>> > >>> Simo. > >>> > >> # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > >> --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign > >> ------------------- > >> Added user "tuser2" > >> ------------------- > >> User login: tuser2 > >> First name: Test > >> Last name: User2 > >> Full name: Test User2 > >> Display name: Test User2 > >> Initials: TU > >> Home directory: /home/tuser2 > >> GECOS field: Test User2 > >> Login shell: /bin/false > >> Kerberos principal: tuser2 at CL.ATIX > >> UID: 473000078 > >> GID: 473000078 > >> Password: False > >> Kerberos keys available: False > >> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" > >> sambaSID > >> SASL/GSSAPI authentication started > >> SASL username: admin at CL.ATIX > >> SASL SSF: 56 > >> SASL data security layer installed. > >> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > >> sambaSID: S-1-5-21-xx-xx-xx-assign > >> > >> The following objectclasses are being set when creating a new user: > >> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" > >> objectClass > >> SASL/GSSAPI authentication started > >> SASL username: admin at CL.ATIX > >> SASL SSF: 56 > >> SASL data security layer installed. > >> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix > >> objectClass: top > >> objectClass: person > >> objectClass: organizationalperson > >> objectClass: inetorgperson > >> objectClass: inetuser > >> objectClass: posixaccount > >> objectClass: krbprincipalaux > >> objectClass: krbticketpolicyaux > >> objectClass: ipaobject > >> objectClass: sambaSAMAccount > >> objectClass: ipasshuser > >> objectClass: ipaSshGroupOfPubKeys > >> objectClass: mepOriginEntry > >> > >> Thanks for your help > > Seem like a DNA bug ... then, > > > > Nathan do you have any idea ? > What DNA configuration is used? >From a previous mail this look to be the config. Marc is this still correct ? Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b "cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config" -D "cn=Directory Manager" -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 16 21:44:35 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Oct 2012 17:44:35 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> <507D86CE.8070306@redhat.com> <20121016170519.GO26626@hendrix.brq.redhat.com> Message-ID: <507DD543.2020706@redhat.com> Macklin, Jason wrote: > Yes, resolution works correctly at both the host and the freeIPA server. > > Dmitri, > > I am still quite new to LDAP so I'm not sure exactly what I should be looking for when running ldapsearch. > > The attempts that I have made have been less then fruitful though... examples follow > > /usr/bin/ldapsearch -I -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com"SASL/EXTERNAL authentication started > ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: > > This sort of return occurs for either working or non-working users both! > > As I am new to ldap... is there a specific ldapsearch command/option I should be using? You want to be authenticated to search the sudo data, so do something like: $ kinit admin (or some user) $ ldapsearch -Y GSSAPI ... rob From nkinder at redhat.com Tue Oct 16 21:51:18 2012 From: nkinder at redhat.com (Nathan Kinder) Date: Tue, 16 Oct 2012 14:51:18 -0700 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350423656.10587.201.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> <1350390085.10587.195.camel@willson.li.ssimo.org> <507DD002.30009@redhat.com> <1350423656.10587.201.camel@willson.li.ssimo.org> Message-ID: <507DD6D6.8090500@redhat.com> On 10/16/2012 02:40 PM, Simo Sorce wrote: > On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: >> On 10/16/2012 05:21 AM, Simo Sorce wrote: >>> On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: >>>> Am 15.10.2012 15:50, schrieb Simo Sorce: >>>>> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: >>>>>> Am 14.10.2012 23:14, schrieb Simo Sorce: >>>>>>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: >>>>>>> Right I am ok with sambaPwdMustChange not being set. That's all good. >>>>>>> What about sambaPwdLastSet ? >>>>>> Not set when a user is created new. >>>>> It should be set when you give the user a password as long at the >>>>> sambaSamAccount objectclass is added to the user. >>>>> >>>>>> When I change the password: >>>>>> sambaPwdLastSet: 0 >>>>> If this is when you set the password as an admin, it is expected. >>>> Ok, understood. But it should change when the user resets his/her >>>> password, right? >>>> And that is not happening. >>>> When the user sets his/her password the sambaPwdLastSet stays untouched. >>> That's odd, how does the user change the password ? >>> >>>>>> Not working with samba! >>>>>> Need to apply my script (see below). >>>>> Let me ask one thing, are you changing the password as a user ? >>>>> Or have you tested only setting the password as admin ? >>>> I set the initial password as admin. >>>> Then the user logs in to a server (sssd, ssh, ipa-member) and is >>>> requested to change his/her password. This works but the sambaPwdLastSet >>>> stays untouched. >>> Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? >>> >>>>> If the latter this applies: >>>>> http://www.freeipa.org/page/NewPasswordsExpired >>>> Checked it. But that was my understanding nevertheless. >>>>> I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign >>>>> >>>>> >>>>> Simo. >>>>> >>>> # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false >>>> --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign I think that this needs to be --setattr=assign. The prefix should not be included when specifying the magic value to trigger generation. >>>> ------------------- >>>> Added user "tuser2" >>>> ------------------- >>>> User login: tuser2 >>>> First name: Test >>>> Last name: User2 >>>> Full name: Test User2 >>>> Display name: Test User2 >>>> Initials: TU >>>> Home directory: /home/tuser2 >>>> GECOS field: Test User2 >>>> Login shell: /bin/false >>>> Kerberos principal: tuser2 at CL.ATIX >>>> UID: 473000078 >>>> GID: 473000078 >>>> Password: False >>>> Kerberos keys available: False >>>> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >>>> sambaSID >>>> SASL/GSSAPI authentication started >>>> SASL username: admin at CL.ATIX >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >>>> sambaSID: S-1-5-21-xx-xx-xx-assign >>>> >>>> The following objectclasses are being set when creating a new user: >>>> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >>>> objectClass >>>> SASL/GSSAPI authentication started >>>> SASL username: admin at CL.ATIX >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >>>> objectClass: top >>>> objectClass: person >>>> objectClass: organizationalperson >>>> objectClass: inetorgperson >>>> objectClass: inetuser >>>> objectClass: posixaccount >>>> objectClass: krbprincipalaux >>>> objectClass: krbticketpolicyaux >>>> objectClass: ipaobject >>>> objectClass: sambaSAMAccount >>>> objectClass: ipasshuser >>>> objectClass: ipaSshGroupOfPubKeys >>>> objectClass: mepOriginEntry >>>> >>>> Thanks for your help >>> Seem like a DNA bug ... then, >>> >>> Nathan do you have any idea ? >> What DNA configuration is used? > >From a previous mail this look to be the config. > > Marc is this still correct ? > > Although my configurations looks ok, doesn't it? > # ldapsearch -LLL -b "cn=SambaSID,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config" -D "cn=Directory Manager" -x -W > Enter LDAP Password: > dn: cn=SambaSid,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-1310149461-105972258- > dnainterval: 1 > dnamagicregen: assign > dnafilter: > (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > dnascope: dc=atix,dc=cl > cn: SambaSid > dnanextvalue: 15400 > From Steven.Jones at vuw.ac.nz Tue Oct 16 21:54:08 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 16 Oct 2012 21:54:08 +0000 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 In-Reply-To: References: Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E9CAD@STAWINCOX10MBX1.staff.vuw.ac.nz> Can you turn on debugging? "sudoers_debug 2" to /etc/sudo-ldap.conf (assumes RHEL6.3) Also you could try adding the host directly to the sudo rule and not via a host group as that seems buggy.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Toasted Penguin [toastedpenguininfo at gmail.com] Sent: Wednesday, 17 October 2012 10:24 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case "sudo su -") it fails and they get the error "user is not allowed to run sudo on client-host. This incident will be reported." I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard "User not in the sudoers file...." Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command "/bin/su", created a sudo rule "Sudo to root" , added the group the user in question is a part of to the WHO-->User Groups; Added the Host Group the target client host is part of to Access This Host-->Host Groups and added the sudo command to the sudo rule via Allow-->Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. Any ideas why or where to look to figure out this issue? Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Tue Oct 16 22:00:04 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 16 Oct 2012 18:00:04 -0400 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <507DD6D6.8090500@redhat.com> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> <1350390085.10587.195.camel@willson.li.ssimo.org> <507DD002.30009@redhat.com> <1350423656.10587.201.camel@willson.li.ssimo.org> <507DD6D6.8090500@redhat.com> Message-ID: <1350424804.10587.203.camel@willson.li.ssimo.org> On Tue, 2012-10-16 at 14:51 -0700, Nathan Kinder wrote: > On 10/16/2012 02:40 PM, Simo Sorce wrote: > > On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: > >> On 10/16/2012 05:21 AM, Simo Sorce wrote: > >>> On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: > >>>> Am 15.10.2012 15:50, schrieb Simo Sorce: > >>>>> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: > >>>>>> Am 14.10.2012 23:14, schrieb Simo Sorce: > >>>>>>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: > >>>>>>> Right I am ok with sambaPwdMustChange not being set. That's all good. > >>>>>>> What about sambaPwdLastSet ? > >>>>>> Not set when a user is created new. > >>>>> It should be set when you give the user a password as long at the > >>>>> sambaSamAccount objectclass is added to the user. > >>>>> > >>>>>> When I change the password: > >>>>>> sambaPwdLastSet: 0 > >>>>> If this is when you set the password as an admin, it is expected. > >>>> Ok, understood. But it should change when the user resets his/her > >>>> password, right? > >>>> And that is not happening. > >>>> When the user sets his/her password the sambaPwdLastSet stays untouched. > >>> That's odd, how does the user change the password ? > >>> > >>>>>> Not working with samba! > >>>>>> Need to apply my script (see below). > >>>>> Let me ask one thing, are you changing the password as a user ? > >>>>> Or have you tested only setting the password as admin ? > >>>> I set the initial password as admin. > >>>> Then the user logs in to a server (sssd, ssh, ipa-member) and is > >>>> requested to change his/her password. This works but the sambaPwdLastSet > >>>> stays untouched. > >>> Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? > >>> > >>>>> If the latter this applies: > >>>>> http://www.freeipa.org/page/NewPasswordsExpired > >>>> Checked it. But that was my understanding nevertheless. > >>>>> I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign > >>>>> > >>>>> > >>>>> Simo. > >>>>> > >>>> # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false > >>>> --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign > I think that this needs to be --setattr=assign. The prefix should not > be included when specifying the magic value to trigger generation. Nathan, you were not included in the previous mails, but options have been tried and they seem to fail the same way (ie the actual passed in value is stored instead of generating a new value). Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 16 22:04:46 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 16 Oct 2012 18:04:46 -0400 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 In-Reply-To: References: Message-ID: <507DD9FE.9080807@redhat.com> Toasted Penguin wrote: > I have the server setup to manage sudo and I configured a target client > to use the IPA server for sudo. When a user tries to use sudo (in this > case "sudo su -") it fails and they get the error "user is not allowed > to run sudo on client-host. This incident will be reported." I verified > via the log files that the client is making requests to the IPA server > when the user is attemping to use sudo and it fails. I temporarily > disabled using the IPA server for sudo and I get the standard "User not > in the sudoers file...." > Its starting to look like the server rules maybe the issue but I believe > I have the sudo rule setup correctly. I created a sudo command > "/bin/su", created a sudo rule "Sudo to root" , added the group the user > in question is a part of to the WHO-->User Groups; Added the Host Group > the target client host is part of to Access This Host-->Host Groups > and added the sudo command to the sudo rule via Allow-->Sudo Allow > Commands. When I delete the sudo rule I get the same result as I did > when I temporarily disbled the client host using tghe IPA server for > sudo verification. > Any ideas why or where to look to figure out this issue? > Thanks, > David I took a look at the docs and they state to edit /etc/nscld.conf. You want /etc/ldap.conf for the configuration. Can you give that a try? Adding sudoers_debug 2 should provide copious information on stdout. rob From dpal at redhat.com Tue Oct 16 22:27:47 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 18:27:47 -0400 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 In-Reply-To: <507DD9FE.9080807@redhat.com> References: <507DD9FE.9080807@redhat.com> Message-ID: <507DDF63.6040002@redhat.com> On 10/16/2012 06:04 PM, Rob Crittenden wrote: > Toasted Penguin wrote: >> I have the server setup to manage sudo and I configured a target client >> to use the IPA server for sudo. When a user tries to use sudo (in this >> case "sudo su -") it fails and they get the error "user is not allowed >> to run sudo on client-host. This incident will be reported." I verified >> via the log files that the client is making requests to the IPA server >> when the user is attemping to use sudo and it fails. I temporarily >> disabled using the IPA server for sudo and I get the standard "User not >> in the sudoers file...." >> Its starting to look like the server rules maybe the issue but I believe >> I have the sudo rule setup correctly. I created a sudo command >> "/bin/su", created a sudo rule "Sudo to root" , added the group the user >> in question is a part of to the WHO-->User Groups; Added the Host Group >> the target client host is part of to Access This Host-->Host Groups >> and added the sudo command to the sudo rule via Allow-->Sudo Allow >> Commands. When I delete the sudo rule I get the same result as I did >> when I temporarily disbled the client host using tghe IPA server for >> sudo verification. >> Any ideas why or where to look to figure out this issue? >> Thanks, >> David > > I took a look at the docs and they state to edit /etc/nscld.conf. You > want /etc/ldap.conf for the configuration. Can you give that a try? > > Adding sudoers_debug 2 should provide copious information on stdout. > Also following another thread might help https://www.redhat.com/archives/freeipa-users/2012-October/msg00097.html > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bjvetter at gmail.com Tue Oct 16 23:30:46 2012 From: bjvetter at gmail.com (Brian Vetter) Date: Tue, 16 Oct 2012 18:30:46 -0500 Subject: [Freeipa-users] web admin tool will not login with kerberos ticket Message-ID: I had a happy, working 2.2 FreeIPA installation humming along last week. I had to do some maintenance so I shut everything down. When I brought everything up, I can no longer log into the web admin tool. I get a "Kerberos ticket is no longer valid" error. Using the troubleshooting pages on the wiki as a guide, I can kinit successfully and see the tickets using klist. I can use the ldapsearch tool using GSSAPI to authenticate as well and can return results from the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin' returns a valid ldap recors for my admin user. I ran this command kinit from multiple kerberos principals/users and each worked. I verified my config settings again with firefox and they are still set correctly (auth.delegation-uris, auth.trusted-users both set to my domain .dcc.mobi). The cert was accepted (no warnings about the cert not being trusted because I had already set it to trusted). I turned on the NSPR logging as described in the documents, and didn't see an error, although I can't tell if this is correct: 492291904[7f4d1d31f6a0]: using REQ_DELEGATE 492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi 492291904[7f4d1d31f6a0]: using negotiate-gss 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI() 492291904[7f4d1d31f6a0]: Attempting to load gss functions 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init() 492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken() 492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0] 492291904[7f4d1d31f6a0]: Sending a token of length 1394 There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log does have a few entries: 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp HTTP/1.1" 200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20100101 Firefox/16.0" 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json HTTP/1.1" 401 - 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos HTTP/1.1" 401 1861 10.1.1.10 - admin at DCC.MOBI [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos HTTP/1.1" 200 - 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json HTTP/1.1" 401 - The 401's aren't surprising here since somehow, something is not properly authenticating. I also looked in /var/log/krb5kdc.log and see the following line when authenticating: Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 tkt=18 ses=18}, admin at DCC.MOBI for krbtgt/DCC.MOBI at DCC.MOBI I don't believe this describes an error, but I'm not an expert reading that log type. From what I can tell, the problems seem to be between the apache server and the browser. Both worked fine together last week. Is there something I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf files) that can help debug this? Or better yet, anyone else seen this and have an answer? Is there some key/ticket/etc associated with the http server that might be "wrong" now (somehow whacked during the reboot)? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Oct 16 23:23:38 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 16 Oct 2012 23:23:38 +0000 Subject: [Freeipa-users] IPA v cron Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E9EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From dpal at redhat.com Tue Oct 16 23:46:32 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 19:46:32 -0400 Subject: [Freeipa-users] web admin tool will not login with kerberos ticket In-Reply-To: References: Message-ID: <507DF1D8.1080108@redhat.com> On 10/16/2012 07:30 PM, Brian Vetter wrote: > I had a happy, working 2.2 FreeIPA installation humming along last > week. I had to do some maintenance so I shut everything down. When I > brought everything up, I can no longer log into the web admin tool. I > get a "Kerberos ticket is no longer valid" error. > > Using the troubleshooting pages on the wiki as a guide, I can kinit > successfully and see the tickets using klist. I can use the ldapsearch > tool using GSSAPI to authenticate as well and can return results from > the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin' > returns a valid ldap recors for my admin user. I ran this command > kinit from multiple kerberos principals/users and each worked. > > I verified my config settings again with firefox and they are still > set correctly (auth.delegation-uris, auth.trusted-users both set to my > domain .dcc.mobi). The cert was accepted (no warnings about the cert > not being trusted because I had already set it to trusted). I turned > on the NSPR logging as described in the documents, and didn't see an > error, although I can't tell if this is correct: > > 492291904[7f4d1d31f6a0]: using REQ_DELEGATE > 492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi > 492291904[7f4d1d31f6a0]: using negotiate-gss > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI() > 492291904[7f4d1d31f6a0]: Attempting to load gss functions > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init() > 492291904[7f4d1d31f6a0]: > nsHttpNegotiateAuth::GenerateCredentials() [challenge=Negotiate] > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken() > 492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0] > 492291904[7f4d1d31f6a0]: Sending a token of length 1394 > > > There is nothing in /var/log/httpd/error_log. > /var/log/httpd/access_log does have a few entries: > > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp > HTTP/1.1" 200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0) > Gecko/20100101 Firefox/16.0" > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json > HTTP/1.1" 401 - > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET > /ipa/session/login_kerberos HTTP/1.1" 401 1861 > 10.1.1.10 - admin at DCC.MOBI > [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos > HTTP/1.1" 200 - > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json > HTTP/1.1" 401 - > > > The 401's aren't surprising here since somehow, something is not > properly authenticating. > > I also looked in /var/log/krb5kdc.log and see the following line when > authenticating: > > Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 > etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 > tkt=18 ses=18}, admin at DCC.MOBI for > krbtgt/DCC.MOBI at DCC.MOBI > > > I don't believe this describes an error, but I'm not an expert reading > that log type. > > From what I can tell, the problems seem to be between the apache > server and the browser. Both worked fine together last week. Is there > something I can turn on in Apache (perhaps in the ipa.conf or > auth_kerb.conf files) that can help debug this? Or better yet, anyone > else seen this and have an answer? Is there some key/ticket/etc > associated with the http server that might be "wrong" now (somehow > whacked during the reboot)? Just to reiterate. 1) You have a server that got rebooted. 2) After reboot "kinit admin" works 3) klist shows tickets 4) logs show no errors 5) You can do ldap search - no problem 6) You stop FF and start it and it says "Kerberos ticket is no longer valid" This is very similar to thread started by David Sastre with title "Problem with webui: kerberos ticket no longer valid". The start of the thread is in August and the end is in September archive. It might have an answer for you. HTH > > Thanks, > > Brian > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Oct 16 23:48:45 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 16 Oct 2012 19:48:45 -0400 Subject: [Freeipa-users] IPA v cron In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546E9EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546E9EA5@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <507DF25D.3060406@redhat.com> On 10/16/2012 07:23 PM, Steven Jones wrote: > Hi, > > I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. > They get denied when they do what? At what moment they get access denied? > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Wed Oct 17 00:29:38 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 17 Oct 2012 00:29:38 +0000 Subject: [Freeipa-users] IPA v cron In-Reply-To: <507DF25D.3060406@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546E9EA5@STAWINCOX10MBX1.staff.vuw.ac.nz>, <507DF25D.3060406@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546E9F26@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Created and added crond to the HBAC rule, now fine. Thanks regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Wednesday, 17 October 2012 12:48 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA v cron On 10/16/2012 07:23 PM, Steven Jones wrote: > Hi, > > I have local users that can use cron, but IPA'd users cannot I get a permission denied via pam, but since a localuser can crontab -e that seems to make no sense. > They get denied when they do what? At what moment they get access denied? > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From JR.Aquino at citrix.com Wed Oct 17 03:50:04 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 17 Oct 2012 03:50:04 +0000 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 In-Reply-To: References: Message-ID: <9220B1CA-5405-44FD-8CAB-95D861C78635@citrix.com> On the host in question Run the command: domainname That wants to match whatever your domain is. If it doesn't it will fail even if you have all the server rules configured correctly. This is a sudo + netgroups/hostgroups 'feature' ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrixonline.com http://www.citrixonline.com On Oct 16, 2012, at 2:26 PM, "Toasted Penguin" wrote: > I have the server setup to manage sudo and I configured a target client to use the IPA server for sudo. When a user tries to use sudo (in this case "sudo su -") it fails and they get the error "user is not allowed to run sudo on client-host. This incident will be reported." I verified via the log files that the client is making requests to the IPA server when the user is attemping to use sudo and it fails. I temporarily disabled using the IPA server for sudo and I get the standard "User not in the sudoers file...." > > Its starting to look like the server rules maybe the issue but I believe I have the sudo rule setup correctly. I created a sudo command "/bin/su", created a sudo rule "Sudo to root" , added the group the user in question is a part of to the WHO-->User Groups; Added the Host Group the target client host is part of to Access This Host-->Host Groups and added the sudo command to the sudo rule via Allow-->Sudo Allow Commands. When I delete the sudo rule I get the same result as I did when I temporarily disbled the client host using tghe IPA server for sudo verification. > > Any ideas why or where to look to figure out this issue? > > Thanks, > David > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From JR.Aquino at citrix.com Wed Oct 17 03:58:40 2012 From: JR.Aquino at citrix.com (JR Aquino) Date: Wed, 17 Oct 2012 03:58:40 +0000 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, Message-ID: <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there. ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. Let me know how things look after trying that. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Jr Aquino | Sr. Information Security Specialist GIAC Certified Incident Handler | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 T: +1 805.690.3478 C: +1 805.717.0365 jr.aquino at citrixonline.com http://www.citrixonline.com On Oct 16, 2012, at 8:34 AM, "Macklin, Jason" > wrote: Working user: [jmacklin at dbduwdu062 log]$ sudo -l LDAP Config Summary =================== uri ldap://dbduvdu145.dbr.roche.com ldap_version 3 sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com bindpw Roche454 bind_timelimit 5000 timelimit 15 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: ldap sudoHost 'ALL' ... MATCH! sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap sudoHost 'ALL' ... MATCH! sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL Non-working user: Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.some.domain.com LDAP Config Summary =================== uri ldap://dbduvdu145.dbr.roche.com ldap_version 3 sudoers_base ou=SUDOers,dc=dbr,dc=roche,dc=com binddn uid=sudo,cn=sysaccounts,cn=etc,dc=dbr,dc=roche,dc=com bindpw Roche454 bind_timelimit 5000 timelimit 15 ssl start_tls tls_checkpeer (yes) tls_cacertfile /etc/ipa/ca.crt =================== sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_initialize(ld, ldap://dbduvdu145.dbr.roche.com) sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: ldap sudoHost 'dbduwdu062.dbr.roche.com' ... not sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062. Cheers, Jason From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Tuesday, October 16, 2012 11:22 AM To: Macklin, Jason {DASB~Branford} Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 11:09 AM, Macklin, Jason wrote: Dmitri, I will give you everything I?ve got. If I can provide something else, let me know! Working User: Sudo debug output: [jmacklin at dbduwdu062 log]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=roche,dc=com sudo: user_matches=1 sudo: host_matches=1 sudo: sudo_ldap_lookup(52)=0x82 [sudo] password for jmacklin: Matching Defaults entries for jmacklin on this host: requiretty, !visiblepw, always_set_home, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin sudo: ldap search '(|(sudoUser=jmacklin)(sudoUser=%jmacklin)(sudoUser=%dbr)(sudoUser=%admins)(sudoUser=ALL))' sudo: ldap search 'sudoUser=+*' User jmacklin may run the following commands on this host: (root) ALL /var/log/secure output: Oct 16 11:00:03 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=jmacklin uid=0 euid=0 tty=/dev/pts/1 ruser=jmacklin rhost= user=jmacklin Oct 16 11:00:04 dbduwdu062 sudo: jmacklin : TTY=pts/1 ; PWD=/var/log ; USER=root ; COMMAND=list Non-working user: Sudo debug output: [asteinfeld at dbduwdu062 ~]$ sudo -l sudo: ldap_set_option: debug -> 0 sudo: ldap_set_option: tls_checkpeer -> 1 sudo: ldap_set_option: tls_cacertfile -> /etc/ipa/ca.crt sudo: ldap_set_option: tls_cacert -> /etc/ipa/ca.crt sudo: ldap_set_option: ldap_version -> 3 sudo: ldap_set_option: timelimit -> 15 sudo: ldap_set_option(LDAP_OPT_NETWORK_TIMEOUT, 5) sudo: ldap_start_tls_s() ok sudo: ldap_sasl_bind_s() ok sudo: no default options found in ou=SUDOers,dc=dbr,dc=domain,dc=com sudo: user_matches=1 sudo: host_matches=0 sudo: sudo_ldap_lookup(52)=0x84 [sudo] password for asteinfeld: Sorry, user asteinfeld may not run sudo on dbduwdu062 /var/log/secure output: Oct 16 11:05:34 dbduwdu062 sudo: pam_unix(sudo:auth): authentication failure; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: pam_sss(sudo:auth): authentication success; logname=asteinfeld uid=0 euid=0 tty=/dev/pts/3 ruser=asteinfeld rhost= user=asteinfeld Oct 16 11:05:35 dbduwdu062 sudo: asteinfeld : command not allowed ; TTY=pts/3 ; PWD=/home2/asteinfeld ; USER=root ; COMMAND=list Cheers. Jason Please set sudoers_debug 2 http://www.doxer.org/learn-linux/modify-sudoers_debug-in-ldap-conf-to-debug-sudo-on-linux-and-solaris/ From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Tuesday, October 16, 2012 10:33 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/16/2012 10:05 AM, Macklin, Jason wrote: When I become the user in question I see the following in the sssd log. [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [test] I think this is a sudo problem before anything else. For a user in which sudo works, host_matches = 1 always returns when debugging is on. For a user that does not work host_matches always equals 0 (zero). Is there any way to see a more detailed debug log from sudo then? It should show what it is looking for and what it is getting back from the server. I am open to troubleshooting the ldap configuration as I am not convinced that it is referencing the host properly. I enroll the clients using FQDN, but noticed that initially, domainname and nisdomainname qould return (none). Fixing these to show the correct domain did not change the behavior of the nodes though. Thanks again! Jason From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Monday, October 15, 2012 5:58 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/15/2012 04:46 PM, Dmitri Pal wrote: On 10/15/2012 04:34 PM, Macklin, Jason wrote: Hi, I apologize up front if this is obvious, but I?m having issues configuring sudo privileges. I currently have an IPA server running FreeIPA 2.2 with sudo configured for our administrators on all hosts. This works fantastic! As soon as I attempt to configure a more specific sudo rule it does not work. In my troubleshooting, I have noticed that from the same host my admin level privileges work, but with another user account setup to just run one command, it fails. I have turned on sudo debugging and the only thing I can find that looks out of sorts is the following: sudo: host_matches=0 As soon as I move the user account that is failing into the admin group it starts to work. I have attempted every iteration of sudo configuration on the server that I can think of. I have setup HBAC and given that a shot as well. At this point I?m completely stumped and would appreciate any help that I can get! What does sudo test return? Yes I meant HBAC. I might confused you and myself so let us start over. First we need to make sure that the authentication happens correctly so if HBAC is set to allow you should see in the SSSD log that access is granted. That will limit the problem to just SUDO. If you have the allow_all HBAC rule and no other rules then we can probably skip this step and move on to trying to solve the actual SUDO part. So with SUDO one of the known issues is the long vs short hostname. Do you by any chance use a short host name for that host? If names are FQDN the next step would be to use ldapsearch from the client and see what LDAP entries the server would return. Thank you in advance for your assistance, Jason _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From grimme at atix.de Wed Oct 17 06:38:30 2012 From: grimme at atix.de (Marc Grimme) Date: Wed, 17 Oct 2012 08:38:30 +0200 Subject: [Freeipa-users] Resynchronize Samba Passwort In-Reply-To: <1350423656.10587.201.camel@willson.li.ssimo.org> References: <5075903C.9070909@atix.de> <1349884462.3879.35.camel@willson.li.ssimo.org> <5076788A.6050703@atix.de> <1349959077.10587.30.camel@willson.li.ssimo.org> <5076EA58.50308@atix.de> <1349971925.10587.115.camel@willson.li.ssimo.org> <5077FD09.5090402@atix.de> <1350051561.10587.136.camel@willson.li.ssimo.org> <50782D6F.5040906@atix.de> <1350249241.10587.183.camel@willson.li.ssimo.org> <507BFE6C.2050700@atix.de> <1350309041.10587.190.camel@willson.li.ssimo.org> <507D158E.7000305@atix.de> <1350390085.10587.195.camel@willson.li.ssimo.org> <507DD002.30009@redhat.com> <1350423656.10587.201.camel@willson.li.ssimo.org> Message-ID: <507E5266.5040900@atix.de> Am 16.10.2012 23:40, schrieb Simo Sorce: > On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: >> On 10/16/2012 05:21 AM, Simo Sorce wrote: >>> On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: >>>> Am 15.10.2012 15:50, schrieb Simo Sorce: >>>>> On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: >>>>>> Am 14.10.2012 23:14, schrieb Simo Sorce: >>>>>>> On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: >>>>>>> Right I am ok with sambaPwdMustChange not being set. That's all good. >>>>>>> What about sambaPwdLastSet ? >>>>>> Not set when a user is created new. >>>>> It should be set when you give the user a password as long at the >>>>> sambaSamAccount objectclass is added to the user. >>>>> >>>>>> When I change the password: >>>>>> sambaPwdLastSet: 0 >>>>> If this is when you set the password as an admin, it is expected. >>>> Ok, understood. But it should change when the user resets his/her >>>> password, right? >>>> And that is not happening. >>>> When the user sets his/her password the sambaPwdLastSet stays untouched. >>> That's odd, how does the user change the password ? >>> >>>>>> Not working with samba! >>>>>> Need to apply my script (see below). >>>>> Let me ask one thing, are you changing the password as a user ? >>>>> Or have you tested only setting the password as admin ? >>>> I set the initial password as admin. >>>> Then the user logs in to a server (sssd, ssh, ipa-member) and is >>>> requested to change his/her password. This works but the sambaPwdLastSet >>>> stays untouched. >>> Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? >>> >>>>> If the latter this applies: >>>>> http://www.freeipa.org/page/NewPasswordsExpired >>>> Checked it. But that was my understanding nevertheless. >>>>> I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign >>>>> >>>>> >>>>> Simo. >>>>> >>>> # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false >>>> --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign >>>> ------------------- >>>> Added user "tuser2" >>>> ------------------- >>>> User login: tuser2 >>>> First name: Test >>>> Last name: User2 >>>> Full name: Test User2 >>>> Display name: Test User2 >>>> Initials: TU >>>> Home directory: /home/tuser2 >>>> GECOS field: Test User2 >>>> Login shell: /bin/false >>>> Kerberos principal: tuser2 at CL.ATIX >>>> UID: 473000078 >>>> GID: 473000078 >>>> Password: False >>>> Kerberos keys available: False >>>> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >>>> sambaSID >>>> SASL/GSSAPI authentication started >>>> SASL username: admin at CL.ATIX >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >>>> sambaSID: S-1-5-21-xx-xx-xx-assign >>>> >>>> The following objectclasses are being set when creating a new user: >>>> # ldapsearch -LLL -b "uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix" >>>> objectClass >>>> SASL/GSSAPI authentication started >>>> SASL username: admin at CL.ATIX >>>> SASL SSF: 56 >>>> SASL data security layer installed. >>>> dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix >>>> objectClass: top >>>> objectClass: person >>>> objectClass: organizationalperson >>>> objectClass: inetorgperson >>>> objectClass: inetuser >>>> objectClass: posixaccount >>>> objectClass: krbprincipalaux >>>> objectClass: krbticketpolicyaux >>>> objectClass: ipaobject >>>> objectClass: sambaSAMAccount >>>> objectClass: ipasshuser >>>> objectClass: ipaSshGroupOfPubKeys >>>> objectClass: mepOriginEntry >>>> >>>> Thanks for your help >>> Seem like a DNA bug ... then, >>> >>> Nathan do you have any idea ? >> What DNA configuration is used? > >From a previous mail this look to be the config. > > Marc is this still correct ? > > Although my configurations looks ok, doesn't it? > # ldapsearch -LLL -b "cn=SambaSID,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config" -D "cn=Directory Manager" -x -W > Enter LDAP Password: > dn: cn=SambaSid,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > dnatype: sambaSID > dnaprefix: S-1-5-21-1310149461-105972258- > dnainterval: 1 > dnamagicregen: assign > dnafilter: > (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) > dnascope: dc=atix,dc=cl > cn: SambaSid > dnanextvalue: 15400 Yes didn't change anything. And I already tried --setattr=sambaSid=assign and --setattr=sambaSid=S-1-5-..-assign. Both didn't lead to an attribute sambaSid being set per user. Thanks Marc. -- Marc Grimme E-Mail: grimme( at )atix.de From david at summersoft.fay-ar.us Wed Oct 17 04:19:55 2012 From: david at summersoft.fay-ar.us (David Summers) Date: Tue, 16 Oct 2012 23:19:55 -0500 Subject: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server? Message-ID: <507E31EB.90602@summersoft.fay-ar.us> I have looked back through the last year of mail archives for this list and haven't yet found anything on this. I spent a day or so trying to get a RHEL6.3 server set up with several clients, Clients: RHEL 6.3 32-bit RHEL 6.3 64-bit RHEL 5.8 32-bit RHEL 5.8 64-bit So far I've been able to get the RHEL 6.3 clients to register and setup up as a client for RHEL 6.3 IPA server but whenever I try to install the ipa-client on RHEL 5.8 I just get the following error: [root at rh5 ~]# ipa-client-install Discovery was successful! Hostname: rh5.summersoft Realm: SUMMERSOFT DNS Domain: summersoft IPA Server: ipaserver.summersoft BaseDN: dc=summersoft Continue to configure the system with these values? [no]: yes User authorized to enroll computers: admin Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Password for admin at SUMMERSOFT: Joining realm failed: SASL Bind failed Local error (-2) ! child exited with 9 Installation failed. Rolling back changes. IPA client is not configured on this system. In the install log: 2012-10-16 23:16:34,410 DEBUG stderr= 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s ipaserver.summersoft -b dc=summersoft 2012-10-16 23:16:35,032 DEBUG stdout= 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! child exited with 9 Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? If so, what am I doing wrong? I tried following both the RHEL 5.8 and RHEL 6.3 install instructions but nothing I have tried is working so far! Thanks in advance for any help or pointers you can provide. - David Summers From rcritten at redhat.com Wed Oct 17 12:49:14 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 08:49:14 -0400 Subject: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server? In-Reply-To: <507E31EB.90602@summersoft.fay-ar.us> References: <507E31EB.90602@summersoft.fay-ar.us> Message-ID: <507EA94A.6020601@redhat.com> David Summers wrote: > > I have looked back through the last year of mail archives for this list > and haven't yet found anything on this. > > I spent a day or so trying to get a RHEL6.3 server set up with several > clients, > > Clients: > RHEL 6.3 32-bit > RHEL 6.3 64-bit > RHEL 5.8 32-bit > RHEL 5.8 64-bit > > So far I've been able to get the RHEL 6.3 clients to register and setup > up as a client for RHEL 6.3 IPA server but whenever I try to install the > ipa-client on RHEL 5.8 I just get the following error: > > [root at rh5 ~]# ipa-client-install > Discovery was successful! > Hostname: rh5.summersoft > Realm: SUMMERSOFT > DNS Domain: summersoft > IPA Server: ipaserver.summersoft > BaseDN: dc=summersoft > > > Continue to configure the system with these values? [no]: yes > User authorized to enroll computers: admin > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Password for admin at SUMMERSOFT: > > Joining realm failed: SASL Bind failed Local error (-2) ! > child exited with 9 > Installation failed. Rolling back changes. > IPA client is not configured on this system. > > In the install log: > > 2012-10-16 23:16:34,410 DEBUG stderr= > 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s > ipaserver.summersoft -b > dc=summersoft > 2012-10-16 23:16:35,032 DEBUG stdout= > 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! > child exited with 9 > > > Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? > > If so, what am I doing wrong? I tried following both the RHEL 5.8 and > RHEL 6.3 install instructions but > nothing I have tried is working so far! > > Thanks in advance for any help or pointers you can provide. > > - David Summers What is the version of the 5.8 ipa-client package? You want ipa-client-2.1.3-2.el5_8 rob From rcritten at redhat.com Wed Oct 17 12:49:57 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 08:49:57 -0400 Subject: [Freeipa-users] web admin tool will not login with kerberos ticket In-Reply-To: References: Message-ID: <507EA975.4000301@redhat.com> Brian Vetter wrote: > I had a happy, working 2.2 FreeIPA installation humming along last > week. I had to do some maintenance so I shut everything down. When I > brought everything up, I can no longer log into the web admin tool. I > get a "Kerberos ticket is no longer valid" error. > > Using the troubleshooting pages on the wiki as a guide, I can kinit > successfully and see the tickets using klist. I can use the ldapsearch > tool using GSSAPI to authenticate as well and can return results from > the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin' > returns a valid ldap recors for my admin user. I ran this command kinit > from multiple kerberos principals/users and each worked. > > I verified my config settings again with firefox and they are still set > correctly (auth.delegation-uris, auth.trusted-users both set to my > domain .dcc.mobi). The cert was accepted (no warnings about the cert not > being trusted because I had already set it to trusted). I turned on the > NSPR logging as described in the documents, and didn't see an error, > although I can't tell if this is correct: > > 492291904[7f4d1d31f6a0]: using REQ_DELEGATE > 492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi > 492291904[7f4d1d31f6a0]: using negotiate-gss > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI() > 492291904[7f4d1d31f6a0]: Attempting to load gss functions > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init() > 492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials() > [challenge=Negotiate] > 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken() > 492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0] > 492291904[7f4d1d31f6a0]: Sending a token of length 1394 > > > There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log > does have a few entries: > > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp HTTP/1.1" > 200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0) > Gecko/20100101 Firefox/16.0" > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json > HTTP/1.1" 401 - > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET > /ipa/session/login_kerberos HTTP/1.1" 401 1861 > 10.1.1.10 - admin at DCC.MOBI > [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos > HTTP/1.1" 200 - > 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json > HTTP/1.1" 401 - > > > The 401's aren't surprising here since somehow, something is not > properly authenticating. > > I also looked in /var/log/krb5kdc.log and see the following line when > authenticating: > > Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 > etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 > tkt=18 ses=18}, admin at DCC.MOBI for > krbtgt/DCC.MOBI at DCC.MOBI > > > I don't believe this describes an error, but I'm not an expert reading > that log type. > > From what I can tell, the problems seem to be between the apache server > and the browser. Both worked fine together last week. Is there something > I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf > files) that can help debug this? Or better yet, anyone else seen this > and have an answer? Is there some key/ticket/etc associated with the > http server that might be "wrong" now (somehow whacked during the reboot)? If you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart the httpd service you'll get a lot of debugging output from ipa and mod_auth_kerb, one of which may provide some pointers. rob From jason.macklin at roche.com Wed Oct 17 13:26:55 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 15:26:55 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> Message-ID: Okay, Rule name: test4 Enabled: TRUE Command category: all Users: asteinfeld Hosts: dbduwdu062.dbr.roche.com Host Groups: tempsudo Client dbduwdu062 is matched in the rule by both the hosts and groups entry. /etc/nsswitch.conf has: Netgroups: files sss Getent netgroup tempsudo returns: [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) To the previous ldapsearch request: [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) additional info: Entry permanently locked. I am still scratching my head on this one... Cheers, Jason If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there. ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. Let me know how things look after trying that. From toastedpenguininfo at gmail.com Wed Oct 17 14:32:55 2012 From: toastedpenguininfo at gmail.com (Toasted Penguin) Date: Wed, 17 Oct 2012 09:32:55 -0500 Subject: [Freeipa-users] Setting up sudo in FreeIPA v2.2 In-Reply-To: <9220B1CA-5405-44FD-8CAB-95D861C78635@citrix.com> References: <9220B1CA-5405-44FD-8CAB-95D861C78635@citrix.com> Message-ID: On Tue, Oct 16, 2012 at 10:50 PM, JR Aquino wrote: > On the host in question Run the command: domainname > > That wants to match whatever your domain is. If it doesn't it will fail > even if you have all the server rules configured correctly. This is a sudo > + netgroups/hostgroups 'feature' > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Jr Aquino | Sr. Information Security Specialist > GIAC Certified Incident Handler | GIAC WebApp Penetration Tester > Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117 > T: +1 805.690.3478 > C: +1 805.717.0365 > jr.aquino at citrixonline.com > http://www.citrixonline.com > > On Oct 16, 2012, at 2:26 PM, "Toasted Penguin" < > toastedpenguininfo at gmail.com> wrote: > > > I have the server setup to manage sudo and I configured a target client > to use the IPA server for sudo. When a user tries to use sudo (in this > case "sudo su -") it fails and they get the error "user is not allowed to > run sudo on client-host. This incident will be reported." I verified via > the log files that the client is making requests to the IPA server when the > user is attemping to use sudo and it fails. I temporarily disabled using > the IPA server for sudo and I get the standard "User not in the sudoers > file...." > > > > Its starting to look like the server rules maybe the issue but I believe > I have the sudo rule setup correctly. I created a sudo command "/bin/su", > created a sudo rule "Sudo to root" , added the group the user in question > is a part of to the WHO-->User Groups; Added the Host Group the target > client host is part of to Access This Host-->Host Groups and added the sudo > command to the sudo rule via Allow-->Sudo Allow Commands. When I delete > the sudo rule I get the same result as I did when I temporarily disbled the > client host using tghe IPA server for sudo verification. > > > > Any ideas why or where to look to figure out this issue? > > > > Thanks, > > David > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > Executing domainname results in the correct domain for theFreeIPA service. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Oct 17 15:53:07 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 09:53:07 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> Message-ID: <507ED463.8020406@redhat.com> On 10/17/2012 07:26 AM, Macklin, Jason wrote: > Okay, > > Rule name: test4 > Enabled: TRUE > Command category: all > Users: asteinfeld > Hosts: dbduwdu062.dbr.roche.com > Host Groups: tempsudo > > Client dbduwdu062 is matched in the rule by both the hosts and groups entry. > > /etc/nsswitch.conf has: > > Netgroups: files sss > > Getent netgroup tempsudo returns: > > [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo > tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) > > To the previous ldapsearch request: > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) > additional info: Entry permanently locked. > > I am still scratching my head on this one... This means you cannot search using your kerberos ticket because the corresponding entry is locked. Try using directory manager: ldapsearch -x -D "cn=directory manager" -W -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > > Cheers, > Jason > > If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. > > When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. > > Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes there. > > ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. > > You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. > > Let me know how things look after trying that. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From dpal at redhat.com Wed Oct 17 15:55:38 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 11:55:38 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> Message-ID: <507ED4FA.6000302@redhat.com> On 10/17/2012 09:26 AM, Macklin, Jason wrote: > Okay, > > Rule name: test4 > Enabled: TRUE > Command category: all > Users: asteinfeld > Hosts: dbduwdu062.dbr.roche.com > Host Groups: tempsudo > > Client dbduwdu062 is matched in the rule by both the hosts and groups entry. > > /etc/nsswitch.conf has: > > Netgroups: files sss > > Getent netgroup tempsudo returns: > > [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo > tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) > > To the previous ldapsearch request: > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) > additional info: Entry permanently locked. It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account. > > I am still scratching my head on this one... > > Cheers, > Jason > > If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. > > When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. > > Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there. > > ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. > > You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. > > Let me know how things look after trying that. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jason.macklin at roche.com Wed Oct 17 16:33:58 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 12:33:58 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507ED4FA.6000302@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> Message-ID: ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" SASL/GSSAPI authentication started SASL username: admin at DBR.ROCHE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <> (default) with scope subtree # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com # requesting: ALL # # search result search: 4 result: 32 No such object # numResponses: 1 Different response, but still no success with the non-working account. Cheers, Jason -----Original Message----- From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Wednesday, October 17, 2012 11:56 AM To: Macklin, Jason {DASB~Branford} Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/17/2012 09:26 AM, Macklin, Jason wrote: > Okay, > > Rule name: test4 > Enabled: TRUE > Command category: all > Users: asteinfeld > Hosts: dbduwdu062.dbr.roche.com > Host Groups: tempsudo > > Client dbduwdu062 is matched in the rule by both the hosts and groups entry. > > /etc/nsswitch.conf has: > > Netgroups: files sss > > Getent netgroup tempsudo returns: > > [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo > tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) > > To the previous ldapsearch request: > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) > additional info: Entry permanently locked. It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account. > > I am still scratching my head on this one... > > Cheers, > Jason > > If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. > > When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. > > Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there. > > ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. > > You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. > > Let me know how things look after trying that. > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From bret.wortman at damascusgrp.com Wed Oct 17 16:40:02 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 17 Oct 2012 12:40:02 -0400 Subject: [Freeipa-users] Failed installation Message-ID: I recently tried installing freeipa on a new server, but ipa-server-install had problems around this point: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/18]: creating certificate server user [2/18]: creating pki-ca instance [3/18]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname fs1.wedgeofli.me-cs_port 9445 -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME -ldap_host fs1.wedgeofli.me -ldap_port 7389 -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX -base_dn o=ipaca -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O= WEDGEOFLI.ME -ca_server_cert_subject_name CN=fs1.wedgeofli.me,O=WEDGEOFLI.ME-ca_audit_signing_cert_subject_name CN=CA Audit,O= WEDGEOFLI.ME -ca_sign_cert_subject_name CN=Certificate Authority,O= WEDGEOFLI.ME -external false -clone false' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed [root at fs1 ~]# The logfile revealed the following stack trace: ############################################# Attempting to connect to: fs1.wedgeofli.me:9445 Exception in LoginPanel(): java.lang.NullPointerException ERROR: ConfigureCA: LoginPanel() failure ERROR: unable to create CA ####################################################################### 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send Request:java.net.ConnectException: Connection refused java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) at java.net.Socket.connect(Socket.java:579) at java.net.Socket.connect(Socket.java:528) at java.net.Socket.(Socket.java:425) at java.net.Socket.(Socket.java:241) at HTTPClient.sslConnect(HTTPClient.java:326) at ConfigureCA.LoginPanel(ConfigureCA.java:244) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) java.lang.NullPointerException at ConfigureCA.LoginPanel(ConfigureCA.java:245) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) at ConfigureCA.main(ConfigureCA.java:1672) Now I seem to be stuck. I tried uninstalling the freeipa-server package with # yum remove freeipa-server and then reinstalled it the same way, but ipa-server-install won't run no matter what I attempt. Any thoughts? I'm pretty new to IPA. Thanks! -- Bret Wortman The Damascus Group Fairfax, VA -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 17 16:46:59 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 17 Oct 2012 12:46:59 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507ED463.8020406@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> Message-ID: <1350492419.30610.47.camel@willson.li.ssimo.org> On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote: > On 10/17/2012 07:26 AM, Macklin, Jason wrote: > > Okay, > > > > Rule name: test4 > > Enabled: TRUE > > Command category: all > > Users: asteinfeld > > Hosts: dbduwdu062.dbr.roche.com > > Host Groups: tempsudo > > > > Client dbduwdu062 is matched in the rule by both the hosts and groups entry. > > > > /etc/nsswitch.conf has: > > > > Netgroups: files sss > > > > Getent netgroup tempsudo returns: > > > > [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo > > tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) > > > > To the previous ldapsearch request: > > > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > > SASL/GSSAPI authentication started > > ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) > > additional info: Entry permanently locked. > > > > I am still scratching my head on this one... > > This means you cannot search using your kerberos ticket because the > corresponding entry is locked. Try using directory manager: > > ldapsearch -x -D "cn=directory manager" -W -H > ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > This sounds very wrong. If the user had a kerberos ticket in the first place it meant it successfully authenticated. If no krb ticket was available GSSAPI would have not started at all. This look like some odd error in directory server failing to recognize valid users ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Wed Oct 17 16:54:16 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 10:54:16 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <1350492419.30610.47.camel@willson.li.ssimo.org> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> Message-ID: <507EE2B8.6020402@redhat.com> On 10/17/2012 10:46 AM, Simo Sorce wrote: > On Wed, 2012-10-17 at 09:53 -0600, Rich Megginson wrote: >> On 10/17/2012 07:26 AM, Macklin, Jason wrote: >>> Okay, >>> >>> Rule name: test4 >>> Enabled: TRUE >>> Command category: all >>> Users: asteinfeld >>> Hosts: dbduwdu062.dbr.roche.com >>> Host Groups: tempsudo >>> >>> Client dbduwdu062 is matched in the rule by both the hosts and groups entry. >>> >>> /etc/nsswitch.conf has: >>> >>> Netgroups: files sss >>> >>> Getent netgroup tempsudo returns: >>> >>> [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo >>> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) >>> >>> To the previous ldapsearch request: >>> >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" >>> SASL/GSSAPI authentication started >>> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) >>> additional info: Entry permanently locked. >>> >>> I am still scratching my head on this one... >> This means you cannot search using your kerberos ticket because the >> corresponding entry is locked. Try using directory manager: >> >> ldapsearch -x -D "cn=directory manager" -W -H >> ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" >> > This sounds very wrong. > > If the user had a kerberos ticket in the first place it meant it > successfully authenticated. > > If no krb ticket was available GSSAPI would have not started at all. > > This look like some odd error in directory server failing to recognize > valid users ? Not sure what's going on. Looking at the code in ipa_lockout.c: lockout_duration = slapi_entry_attr_get_uint(policy_entry, "krbPwdLockoutDuration"); if (lockout_duration == 0) { errstr = "Entry permanently locked.\n"; ret = LDAP_UNWILLING_TO_PERFORM; goto done; } This means either krbPwdLockoutDuration does not exist at all, or does exist and has a value of 0. Can you do an ldapsearch of your entry like this: ldapsearch -xLLL -D "cn=directory manager" -W uid=youruserid \* krbPwdLockoutDuration ? > > Simo. > From dpal at redhat.com Wed Oct 17 16:58:28 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 12:58:28 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> Message-ID: <507EE3B4.9050803@redhat.com> On 10/17/2012 12:33 PM, Macklin, Jason wrote: > ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" You are missing -b ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" Currently the command treats it as filter and thus returns no results. I am asking you to run this command to see what LDAP data the server presents to the client. Running this would not cure the problem but rather might give more hints of what the actual problem is. > SASL/GSSAPI authentication started > SASL username: admin at DBR.ROCHE.COM > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base <> (default) with scope subtree > # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > > # numResponses: 1 > > Different response, but still no success with the non-working account. > > Cheers, > Jason > > -----Original Message----- > From: Dmitri Pal [mailto:dpal at redhat.com] > Sent: Wednesday, October 17, 2012 11:56 AM > To: Macklin, Jason {DASB~Branford} > Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 09:26 AM, Macklin, Jason wrote: >> Okay, >> >> Rule name: test4 >> Enabled: TRUE >> Command category: all >> Users: asteinfeld >> Hosts: dbduwdu062.dbr.roche.com >> Host Groups: tempsudo >> >> Client dbduwdu062 is matched in the rule by both the hosts and groups entry. >> >> /etc/nsswitch.conf has: >> >> Netgroups: files sss >> >> Getent netgroup tempsudo returns: >> >> [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo >> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) >> >> To the previous ldapsearch request: >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) >> additional info: Entry permanently locked. > It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account. > >> I am still scratching my head on this one... >> >> Cheers, >> Jason >> >> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. >> >> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. >> >> Try this. Type: getent netgroup hostgroupname <- your host's hostgroup goes there. >> >> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. >> >> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. >> >> Let me know how things look after trying that. >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rmeggins at redhat.com Wed Oct 17 16:58:42 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 10:58:42 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> Message-ID: <507EE3C2.30203@redhat.com> On 10/17/2012 10:33 AM, Macklin, Jason wrote: > ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > SASL username: admin at DBR.ROCHE.COM > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base<> (default) with scope subtree > # filter: ou=SUDOers,dc=dbr,dc=roche,dc=com > # requesting: ALL > # > > # search result > search: 4 > result: 32 No such object > > # numResponses: 1 > > Different response, but still no success with the non-working account. Sorry - the ldapsearch command is wrong. Try this: ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" > > Cheers, > Jason > > -----Original Message----- > From: Dmitri Pal [mailto:dpal at redhat.com] > Sent: Wednesday, October 17, 2012 11:56 AM > To: Macklin, Jason {DASB~Branford} > Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 09:26 AM, Macklin, Jason wrote: >> Okay, >> >> Rule name: test4 >> Enabled: TRUE >> Command category: all >> Users: asteinfeld >> Hosts: dbduwdu062.dbr.roche.com >> Host Groups: tempsudo >> >> Client dbduwdu062 is matched in the rule by both the hosts and groups entry. >> >> /etc/nsswitch.conf has: >> >> Netgroups: files sss >> >> Getent netgroup tempsudo returns: >> >> [jmacklin at dbduwdu062 Desktop]$ getent netgroup tempsudo >> tempsudo (dbduwdu063.dbr.roche.com, -, dbr.roche.com) (dbduwdu062.dbr.roche.com, -, dbr.roche.com) >> >> To the previous ldapsearch request: >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com "ou=SUDOers,dc=dbr,dc=roche,dc=com" >> SASL/GSSAPI authentication started >> ldap_sasl_interactive_bind_s: Server is unwilling to perform (53) >> additional info: Entry permanently locked. > It seems that you tried the wrong password and the account is now temporarily locked thus the server is unwilling to perform authentication for this account. > >> I am still scratching my head on this one... >> >> Cheers, >> Jason >> >> If you look closely, the reason that your admin works is because it appears to be matching a sudo rule who has the "ALL" hosts value set. >> >> When you run the non working user, it is attempting to match the hostname/hostgroup to the rule and fails to do so. >> >> Try this. Type: getent netgroup hostgroupname<- your host's hostgroup goes there. >> >> ^ that command should return all of the hosts in your hostgroup. If it does not, then check /etc/nsswitch.conf and make sure that netgroup is set to use sss. >> >> You will also need to make sure that the output of: domainname or nisdomainname matches your expected domain. >> >> Let me know how things look after trying that. >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From jason.macklin at roche.com Wed Oct 17 17:05:37 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 13:05:37 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EE3B4.9050803@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> Message-ID: Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me. [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" SASL/GSSAPI authentication started SASL username: admin at DBR.ROCHE.COM SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # sudoers, dbr.roche.com dn: ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: extensibleObject ou: sudoers # test4, sudoers, dbr.roche.com dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: asteinfeld sudoHost: dbduwdu062.dbr.roche.com sudoHost: +tempsudo sudoCommand: ALL cn: test4 # switch, sudoers, dbr.roche.com dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: oyilmaz sudoHost: dbdusdu071.dbr.roche.com sudoCommand: /bin/su cn: switch # jing144, sudoers, dbr.roche.com dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jli sudoHost: dbduvdu144.dbr.roche.com sudoCommand: ALL cn: jing144 # Admin, sudoers, dbr.roche.com dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com objectClass: sudoRole sudoUser: jmacklin sudoUser: mrini sudoUser: cgajare sudoUser: parnold sudoUser: hhebert sudoUser: ckuecherer sudoUser: gferreri sudoHost: ALL sudoCommand: ALL cn: Admin # search result search: 4 result: 0 Success # numResponses: 6 # numEntries: 5 I really appreciate all of the help! Cheers, Jason From jason.macklin at roche.com Wed Oct 17 17:13:22 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 13:13:22 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EE2B8.6020402@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> Message-ID: None of my users have an LDAP password being requested by running that command (except the admin user). Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) From rmeggins at redhat.com Wed Oct 17 17:15:06 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 11:15:06 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> Message-ID: <507EE79A.5000705@redhat.com> On 10/17/2012 11:13 AM, Macklin, Jason wrote: > None of my users have an LDAP password being requested by running that command (except the admin user). > > Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) You have to specify which server to talk to using the -H ldap://fqdn.of.host option. From jason.macklin at roche.com Wed Oct 17 17:21:39 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 19:21:39 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EE79A.5000705@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> Message-ID: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? Enter LDAP Password: ldap_bind: Invalid credentials (49) I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. -----Original Message----- From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, October 17, 2012 1:15 PM To: Macklin, Jason {DASB~Branford} Cc: simo at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/17/2012 11:13 AM, Macklin, Jason wrote: > None of my users have an LDAP password being requested by running that command (except the admin user). > > Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) You have to specify which server to talk to using the -H ldap://fqdn.of.host option. From rcritten at redhat.com Wed Oct 17 17:29:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 13:29:09 -0400 Subject: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server? In-Reply-To: <507EE6EF.6040109@summersoft.fay-ar.us> References: <507E31EB.90602@summersoft.fay-ar.us> <507EA94A.6020601@redhat.com> <507EE6EF.6040109@summersoft.fay-ar.us> Message-ID: <507EEAE5.1070702@redhat.com> David Summers wrote: > On 10/17/2012 7:49 AM, Rob Crittenden wrote: >> David Summers wrote: >>> >>> I have looked back through the last year of mail archives for this list >>> and haven't yet found anything on this. >>> >>> I spent a day or so trying to get a RHEL6.3 server set up with several >>> clients, >>> >>> Clients: >>> RHEL 6.3 32-bit >>> RHEL 6.3 64-bit >>> RHEL 5.8 32-bit >>> RHEL 5.8 64-bit >>> >>> So far I've been able to get the RHEL 6.3 clients to register and setup >>> up as a client for RHEL 6.3 IPA server but whenever I try to install the >>> ipa-client on RHEL 5.8 I just get the following error: >>> >>> [root at rh5 ~]# ipa-client-install >>> Discovery was successful! >>> Hostname: rh5.summersoft >>> Realm: SUMMERSOFT >>> DNS Domain: summersoft >>> IPA Server: ipaserver.summersoft >>> BaseDN: dc=summersoft >>> >>> >>> Continue to configure the system with these values? [no]: yes >>> User authorized to enroll computers: admin >>> Synchronizing time with KDC... >>> Unable to sync time with IPA NTP server, assuming the time is in sync. >>> Password for admin at SUMMERSOFT: >>> >>> Joining realm failed: SASL Bind failed Local error (-2) ! >>> child exited with 9 >>> Installation failed. Rolling back changes. >>> IPA client is not configured on this system. >>> >>> In the install log: >>> >>> 2012-10-16 23:16:34,410 DEBUG stderr= >>> 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s >>> ipaserver.summersoft -b >>> dc=summersoft >>> 2012-10-16 23:16:35,032 DEBUG stdout= >>> 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! >>> child exited with 9 >>> >>> >>> Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? >>> >>> If so, what am I doing wrong? I tried following both the RHEL 5.8 and >>> RHEL 6.3 install instructions but >>> nothing I have tried is working so far! >>> >>> Thanks in advance for any help or pointers you can provide. >>> >>> - David Summers >> >> What is the version of the 5.8 ipa-client package? You want >> ipa-client-2.1.3-2.el5_8 >> >> rob >> > > Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it > to join the IPA server. > I've turned off all firewalls. > > I am running IPv6, does that make a difference? > > Any ideas? > > - Thanks > - David Summers It is failing trying to get a keytab for the newly enrolled host. Can you provide /var/log/ipaclient-install.log? Can you look in the 389-ds error and access logs for the BIND request and/or other errors when the client enrollment happens (/var/log/dirsrv/slapd-REALM, access buffers for 30 seconds) and the KDC logs in /var/log/krb5kdc? rob From david at summersoft.fay-ar.us Wed Oct 17 17:12:15 2012 From: david at summersoft.fay-ar.us (David Summers) Date: Wed, 17 Oct 2012 12:12:15 -0500 Subject: [Freeipa-users] RHEL5 IPA client for RHEL6.3 IPA server? In-Reply-To: <507EA94A.6020601@redhat.com> References: <507E31EB.90602@summersoft.fay-ar.us> <507EA94A.6020601@redhat.com> Message-ID: <507EE6EF.6040109@summersoft.fay-ar.us> On 10/17/2012 7:49 AM, Rob Crittenden wrote: > David Summers wrote: >> >> I have looked back through the last year of mail archives for this list >> and haven't yet found anything on this. >> >> I spent a day or so trying to get a RHEL6.3 server set up with several >> clients, >> >> Clients: >> RHEL 6.3 32-bit >> RHEL 6.3 64-bit >> RHEL 5.8 32-bit >> RHEL 5.8 64-bit >> >> So far I've been able to get the RHEL 6.3 clients to register and setup >> up as a client for RHEL 6.3 IPA server but whenever I try to install the >> ipa-client on RHEL 5.8 I just get the following error: >> >> [root at rh5 ~]# ipa-client-install >> Discovery was successful! >> Hostname: rh5.summersoft >> Realm: SUMMERSOFT >> DNS Domain: summersoft >> IPA Server: ipaserver.summersoft >> BaseDN: dc=summersoft >> >> >> Continue to configure the system with these values? [no]: yes >> User authorized to enroll computers: admin >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP server, assuming the time is in sync. >> Password for admin at SUMMERSOFT: >> >> Joining realm failed: SASL Bind failed Local error (-2) ! >> child exited with 9 >> Installation failed. Rolling back changes. >> IPA client is not configured on this system. >> >> In the install log: >> >> 2012-10-16 23:16:34,410 DEBUG stderr= >> 2012-10-16 23:16:35,032 DEBUG args=/usr/sbin/ipa-join -s >> ipaserver.summersoft -b >> dc=summersoft >> 2012-10-16 23:16:35,032 DEBUG stdout= >> 2012-10-16 23:16:35,032 DEBUG stderr=SASL Bind failed Local error (-2) ! >> child exited with 9 >> >> >> Is RHEL 5.8 a supported client for RHEL 6.3 IPA server? >> >> If so, what am I doing wrong? I tried following both the RHEL 5.8 and >> RHEL 6.3 install instructions but >> nothing I have tried is working so far! >> >> Thanks in advance for any help or pointers you can provide. >> >> - David Summers > > What is the version of the 5.8 ipa-client package? You want > ipa-client-2.1.3-2.el5_8 > > rob > Yes, I have ipa-client-2.1.3-2.el5_8 but I have not been able to get it to join the IPA server. I've turned off all firewalls. I am running IPv6, does that make a difference? Any ideas? - Thanks - David Summers From rcritten at redhat.com Wed Oct 17 17:37:19 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 13:37:19 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> Message-ID: <507EECCF.3090508@redhat.com> Macklin, Jason wrote: > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. You use the password of the user you are binding as, in this case the directory manager. rob > > -----Original Message----- > From: Rich Megginson [mailto:rmeggins at redhat.com] > Sent: Wednesday, October 17, 2012 1:15 PM > To: Macklin, Jason {DASB~Branford} > Cc: simo at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 11:13 AM, Macklin, Jason wrote: >> None of my users have an LDAP password being requested by running that command (except the admin user). >> >> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > You have to specify which server to talk to using the -H ldap://fqdn.of.host option. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From dpal at redhat.com Wed Oct 17 17:43:12 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 13:43:12 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: Message-ID: <507EEE30.1030100@redhat.com> On 10/17/2012 12:40 PM, Bret Wortman wrote: > I recently tried installing freeipa on a new server, but > ipa-server-install had problems around this point: > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/18]: creating certificate server user > [2/18]: creating pki-ca instance > [3/18]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > fs1.wedgeofli.me -cs_port 9445 > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin > -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME > -ldap_host fs1.wedgeofli.me > -ldap_port 7389 -bind_dn cn=Directory > Manager -bind_XXXXXXXX XXXXXXXX -base_dn o=ipaca -db_name ipaca > -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12 > true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name internal > -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME > -ca_ocsp_cert_subject_name CN=OCSP > Subsystem,O=WEDGEOFLI.ME > -ca_server_cert_subject_name CN=fs1.wedgeofli.me > ,O=WEDGEOFLI.ME > -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME > -ca_sign_cert_subject_name CN=Certificate > Authority,O=WEDGEOFLI.ME -external false -clone > false' returned non-zero exit status 255 > Unexpected error - see ipaserver-install.log for details: > Configuration of CA failed > [root at fs1 ~]# > > The logfile revealed the following stack trace: > > ############################################# > Attempting to connect to: fs1.wedgeofli.me:9445 > > Exception in LoginPanel(): java.lang.NullPointerException > ERROR: ConfigureCA: LoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send > Request:java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) > at java.net.Socket.connect(Socket.java:579) > at java.net.Socket.connect(Socket.java:528) > at java.net.Socket.(Socket.java:425) > at java.net.Socket.(Socket.java:241) > at HTTPClient.sslConnect(HTTPClient.java:326) > at ConfigureCA.LoginPanel(ConfigureCA.java:244) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > java.lang.NullPointerException > at ConfigureCA.LoginPanel(ConfigureCA.java:245) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > > Now I seem to be stuck. I tried uninstalling the freeipa-server > package with # yum remove freeipa-server and then reinstalled it the > same way, but ipa-server-install won't run no matter what I attempt. > > Any thoughts? I'm pretty new to IPA. > Make sure you have packages installed Run the uninstall command several times (5 for example) ipa-server-install --uninstall -U In case of failed installation and other steps you made the installtion might be in the corrupted state. Running severl times might help as it might detect and remove/unconfigure different things at different moments. Before trying to reinstall again make sure you have latest SELinux policies. If it explodes again let us know. > Thanks! > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdennis at redhat.com Wed Oct 17 17:45:44 2012 From: jdennis at redhat.com (John Dennis) Date: Wed, 17 Oct 2012 13:45:44 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: Message-ID: <507EEEC8.4090607@redhat.com> On 10/17/2012 12:40 PM, Bret Wortman wrote: > I recently tried installing freeipa on a new server, but > ipa-server-install had problems around this point: > > Configuring certificate server: Estimated time 3 minutes 30 seconds > [1/18]: creating certificate server user > [2/18]: creating pki-ca instance > [3/18]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > fs1.wedgeofli.me -cs_port 9445 > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin > -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME > -ldap_host fs1.wedgeofli.me -ldap_port 7389 > -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX -base_dn o=ipaca > -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name > internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=WEDGEOFLI.ME > -ca_ocsp_cert_subject_name CN=OCSP > Subsystem,O=WEDGEOFLI.ME > -ca_server_cert_subject_name CN=fs1.wedgeofli.me > ,O=WEDGEOFLI.ME > -ca_audit_signing_cert_subject_name CN=CA Audit,O=WEDGEOFLI.ME > -ca_sign_cert_subject_name CN=Certificate > Authority,O=WEDGEOFLI.ME -external false -clone > false' returned non-zero exit status 255 > Unexpected error - see ipaserver-install.log for details: > Configuration of CA failed > [root at fs1 ~]# > > The logfile revealed the following stack trace: > > ############################################# > Attempting to connect to: fs1.wedgeofli.me:9445 > > Exception in LoginPanel(): java.lang.NullPointerException > ERROR: ConfigureCA: LoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send > Request:java.net.ConnectException: Connection refused > java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) > at > java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) > at > java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) > at java.net.Socket.connect(Socket.java:579) > at java.net.Socket.connect(Socket.java:528) > at java.net.Socket.(Socket.java:425) > at java.net.Socket.(Socket.java:241) > at HTTPClient.sslConnect(HTTPClient.java:326) > at ConfigureCA.LoginPanel(ConfigureCA.java:244) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > java.lang.NullPointerException > at ConfigureCA.LoginPanel(ConfigureCA.java:245) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > > Now I seem to be stuck. I tried uninstalling the freeipa-server package > with # yum remove freeipa-server and then reinstalled it the same way, > but ipa-server-install won't run no matter what I attempt. > > Any thoughts? I'm pretty new to IPA. There is a good chance this is due to a version mismatch between the IPA packages and the dogtag packages. You didn't mention which OS you're using nor the versions of the relevant packages, that would have been helpful. In any event I would make sure all your packages are up to date. -- John Dennis Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jason.macklin at roche.com Wed Oct 17 17:51:30 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 13:51:30 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EECCF.3090508@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> Message-ID: I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials" ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? Enter LDAP Password: No such object (32) Working account returns same thing... ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? Enter LDAP Password: No such object (32) -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 17, 2012 1:37 PM To: Macklin, Jason {DASB~Branford} Cc: rmeggins at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. Macklin, Jason wrote: > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. You use the password of the user you are binding as, in this case the directory manager. rob > > -----Original Message----- > From: Rich Megginson [mailto:rmeggins at redhat.com] > Sent: Wednesday, October 17, 2012 1:15 PM > To: Macklin, Jason {DASB~Branford} > Cc: simo at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 11:13 AM, Macklin, Jason wrote: >> None of my users have an LDAP password being requested by running that command (except the admin user). >> >> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > You have to specify which server to talk to using the -H ldap://fqdn.of.host option. > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rmeggins at redhat.com Wed Oct 17 18:01:45 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 12:01:45 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> Message-ID: <507EF289.3040003@redhat.com> On 10/17/2012 11:21 AM, Macklin, Jason wrote: > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > ldap_bind: Invalid credentials (49) > > I know this user password user password? It's asking you for the directory manager password. > because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. You get Invalid credentials (49)? > > -----Original Message----- > From: Rich Megginson [mailto:rmeggins at redhat.com] > Sent: Wednesday, October 17, 2012 1:15 PM > To: Macklin, Jason {DASB~Branford} > Cc: simo at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 11:13 AM, Macklin, Jason wrote: >> None of my users have an LDAP password being requested by running that command (except the admin user). >> >> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) > You have to specify which server to talk to using the -H ldap://fqdn.of.host option. From rmeggins at redhat.com Wed Oct 17 18:05:37 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 12:05:37 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> Message-ID: <507EF371.8070804@redhat.com> On 10/17/2012 11:51 AM, Macklin, Jason wrote: > I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials" > > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > No such object (32) > > Working account returns same thing... > > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? > Enter LDAP Password: > No such object (32) Sorry, I though ipa would have configured your /etc/openldap/ldap.conf with your base dn. Try this: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \* > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 17, 2012 1:37 PM > To: Macklin, Jason {DASB~Branford} > Cc: rmeggins at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > Macklin, Jason wrote: >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_bind: Invalid credentials (49) >> >> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. > You use the password of the user you are binding as, in this case the directory manager. > > rob > >> -----Original Message----- >> From: Rich Megginson [mailto:rmeggins at redhat.com] >> Sent: Wednesday, October 17, 2012 1:15 PM >> To: Macklin, Jason {DASB~Branford} >> Cc: simo at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. >> >> On 10/17/2012 11:13 AM, Macklin, Jason wrote: >>> None of my users have an LDAP password being requested by running that command (except the admin user). >>> >>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >>> >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> You have to specify which server to talk to using the -H ldap://fqdn.of.host option. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> From bret.wortman at damascusgrp.com Wed Oct 17 18:31:03 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 17 Oct 2012 14:31:03 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> Message-ID: Now it appears that whatever is supposed to be running on port 9445 (looks like mindarray-ca) isn't running, and I'm not sure how it gets started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA test box I first set up, and it's running on the test box but not the new one. Where should I look next? On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman wrote: > Spot on. It was a fresh install of F17 and I neglected to # yum update > first. I've done so, rebooted, and am trying again with better results. > > > On Wed, Oct 17, 2012 at 1:45 PM, John Dennis wrote: > >> On 10/17/2012 12:40 PM, Bret Wortman wrote: >> >>> I recently tried installing freeipa on a new server, but >>> ipa-server-install had problems around this point: >>> >>> Configuring certificate server: Estimated time 3 minutes 30 seconds >>> [1/18]: creating certificate server user >>> [2/18]: creating pki-ca instance >>> [3/18]: configuring certificate server instance >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>> fs1.wedgeofli.me -cs_port 9445 >>> >>> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX >>> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user admin >>> -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name >>> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa >>> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME >>> -ldap_host fs1.wedgeofli.me -ldap_port 7389 >>> >>> -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX -base_dn o=ipaca >>> -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA >>> -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad -token_name >>> internal -ca_subsystem_cert_subject_**name CN=CA Subsystem,O= >>> WEDGEOFLI.ME >>> -ca_ocsp_cert_subject_name CN=OCSP >>> Subsystem,O=WEDGEOFLI.ME >>> -ca_server_cert_subject_name CN=fs1.wedgeofli.me >>> ,O=WE**DGEOFLI.ME < >>> http://WEDGEOFLI.ME> >>> -ca_audit_signing_cert_**subject_name CN=CA Audit,O=WEDGEOFLI.ME >>> -ca_sign_cert_subject_name CN=Certificate >>> Authority,O=WEDGEOFLI.ME -external false -clone >>> >>> false' returned non-zero exit status 255 >>> Unexpected error - see ipaserver-install.log for details: >>> Configuration of CA failed >>> [root at fs1 ~]# >>> >>> The logfile revealed the following stack trace: >>> >>> ##############################**############### >>> Attempting to connect to: fs1.wedgeofli.me:9445 >>> >>> >>> Exception in LoginPanel(): java.lang.NullPointerException >>> ERROR: ConfigureCA: LoginPanel() failure >>> ERROR: unable to create CA >>> >>> ##############################**##############################** >>> ########### >>> >>> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send >>> Request:java.net.**ConnectException: Connection refused >>> java.net.ConnectException: Connection refused >>> at java.net.PlainSocketImpl.**socketConnect(Native Method) >>> at >>> java.net.**AbstractPlainSocketImpl.**doConnect(** >>> AbstractPlainSocketImpl.java:**339) >>> at >>> java.net.**AbstractPlainSocketImpl.**connectToAddress(** >>> AbstractPlainSocketImpl.java:**200) >>> at >>> java.net.**AbstractPlainSocketImpl.**connect(** >>> AbstractPlainSocketImpl.java:**182) >>> at java.net.SocksSocketImpl.**connect(SocksSocketImpl.java:**391) >>> at java.net.Socket.connect(**Socket.java:579) >>> at java.net.Socket.connect(**Socket.java:528) >>> at java.net.Socket.(Socket.**java:425) >>> at java.net.Socket.(Socket.**java:241) >>> at HTTPClient.sslConnect(**HTTPClient.java:326) >>> at ConfigureCA.LoginPanel(**ConfigureCA.java:244) >>> at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157) >>> at ConfigureCA.main(ConfigureCA.**java:1672) >>> java.lang.NullPointerException >>> at ConfigureCA.LoginPanel(**ConfigureCA.java:245) >>> at ConfigureCA.**ConfigureCAInstance(**ConfigureCA.java:1157) >>> at ConfigureCA.main(ConfigureCA.**java:1672) >>> >>> Now I seem to be stuck. I tried uninstalling the freeipa-server package >>> with # yum remove freeipa-server and then reinstalled it the same way, >>> but ipa-server-install won't run no matter what I attempt. >>> >>> Any thoughts? I'm pretty new to IPA. >>> >> >> There is a good chance this is due to a version mismatch between the IPA >> packages and the dogtag packages. You didn't mention which OS you're using >> nor the versions of the relevant packages, that would have been helpful. In >> any event I would make sure all your packages are up to date. >> >> >> -- >> John Dennis >> >> >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ >> > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Oct 17 18:44:08 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 14:44:08 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> Message-ID: <507EFC78.9030007@redhat.com> On 10/17/2012 02:31 PM, Bret Wortman wrote: > Now it appears that whatever is supposed to be running on port 9445 > (looks like mindarray-ca) isn't running, and I'm not sure how it gets > started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA > test box I first set up, and it's running on the test box but not the > new one. Where should I look next? You cert system component failed to start because its DS instance failed to start. Did the install fail again after cleanup? If not it is better to start over with cleanup and if the install fails we will help you to troubleshoot. > > On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman > > > wrote: > > Spot on. It was a fresh install of F17 and I neglected to # yum > update first. I've done so, rebooted, and am trying again with > better results. > > > On Wed, Oct 17, 2012 at 1:45 PM, John Dennis > wrote: > > On 10/17/2012 12:40 PM, Bret Wortman wrote: > > I recently tried installing freeipa on a new server, but > ipa-server-install had problems around this point: > > Configuring certificate server: Estimated time 3 minutes > 30 seconds > [1/18]: creating certificate server user > [2/18]: creating pki-ca instance > [3/18]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > fs1.wedgeofli.me > -cs_port 9445 > > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA > -admin_user admin > -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX > -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME > > -ldap_host fs1.wedgeofli.me > -ldap_port 7389 > > -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX > -base_dn o=ipaca > -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm > SHA256withRSA > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name > pki-cad -token_name > internal -ca_subsystem_cert_subject_name CN=CA > Subsystem,O=WEDGEOFLI.ME > -ca_ocsp_cert_subject_name CN=OCSP > Subsystem,O=WEDGEOFLI.ME > > -ca_server_cert_subject_name CN=fs1.wedgeofli.me > > ,O=WEDGEOFLI.ME > > -ca_audit_signing_cert_subject_name CN=CA > Audit,O=WEDGEOFLI.ME > -ca_sign_cert_subject_name > CN=Certificate > Authority,O=WEDGEOFLI.ME > -external false -clone > > false' returned non-zero exit status 255 > Unexpected error - see ipaserver-install.log for details: > Configuration of CA failed > [root at fs1 ~]# > > The logfile revealed the following stack trace: > > ############################################# > Attempting to connect to: fs1.wedgeofli.me:9445 > > > > Exception in LoginPanel(): java.lang.NullPointerException > ERROR: ConfigureCA: LoginPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send > Request:java.net .ConnectException: > Connection refused > java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.socketConnect(Native Method) > at > java.net > .AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:339) > at > java.net > .AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:200) > at > java.net > .AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:182) > at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:391) > at java.net.Socket.connect(Socket.java:579) > at java.net.Socket.connect(Socket.java:528) > at java.net.Socket.(Socket.java:425) > at java.net.Socket.(Socket.java:241) > at HTTPClient.sslConnect(HTTPClient.java:326) > at ConfigureCA.LoginPanel(ConfigureCA.java:244) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > java.lang.NullPointerException > at ConfigureCA.LoginPanel(ConfigureCA.java:245) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.java:1672) > > Now I seem to be stuck. I tried uninstalling the > freeipa-server package > with # yum remove freeipa-server and then reinstalled it > the same way, > but ipa-server-install won't run no matter what I attempt. > > Any thoughts? I'm pretty new to IPA. > > > There is a good chance this is due to a version mismatch > between the IPA packages and the dogtag packages. You didn't > mention which OS you're using nor the versions of the relevant > packages, that would have been helpful. In any event I would > make sure all your packages are up to date. > > > -- > John Dennis > > > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.macklin at roche.com Wed Oct 17 18:49:36 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 20:49:36 +0200 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EF371.8070804@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> <507EF371.8070804@redhat.com> Message-ID: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \* Enter LDAP Password: dn: uid=asteinfeld,cn=users,cn=compat,dc=dbr,dc=roche,dc=com objectClass: posixAccount objectClass: top gecos: Axel Steinfeld cn: Axel Steinfeld uidNumber: 2011 gidNumber: 2011 loginShell: /bin/bash homeDirectory: /home2/asteinfeld uid: asteinfeld dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com displayName: Axel Steinfeld cn: Axel Steinfeld objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/bash sn: Steinfeld uidNumber: 2011 gidNumber: 2011 gecos: Axel Steinfeld homeDirectory: /home2/asteinfeld krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc =roche,dc=com krbPrincipalName: asteinfeld at DBR.ROCHE.COM givenName: Axel uid: asteinfeld initials: AS userPassword:: e1NTSEF9OGpRZ09pazNWbGV0QlRTdm9DSjQ5b0VwaDhIQzZ5aHJ6Z2Foanc9PQ= = ipaUniqueID: e582ea10-9e89-11e1-a7db-005056bb0010 krbPrincipalKey:: MIIC7qADAgEBoQMCAQGiAwIBA6MDAgEBpIIC1jCCAtIwb6AiMCCgAwIBAKEZ BBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKFJMEegAwIBEqFABD4gAKO2YZ6bzFkcvDQUQR1R0AEFO o+oNDP7NlR75fVLZ0932O8fxrDnbKL90Ti3N6AQJpaZzvUrDozy70LSbjBfoCIwIKADAgEAoRkEF0 RCUi5ST0NIRS5DT01hc3RlaW5mZWxkoTkwN6ADAgERoTAELhAAIROPMbj/O/5yV9gynI1rc2CtckV mu7PczKYvb0O/Wk8D8QwBQyFSryrwMQAwZ6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWlu ZmVsZKFBMD+gAwIBEKE4BDYYANU+Z6tmBZfUx5d7gf6NazwtXIlJsxZQZ8ntFigMGQxTjk4W/hDiz ECD0a6hskJuhmi8OjAwX6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0ZWluZmVsZKE5MDegAw IBF6EwBC4QADS3VnBvucc3YHvX0sL9YiASCYV7Iq5UV2seIw4bYlWt0b5RpLR5/fpbPyA5MFegIjA goAMCAQChGQQXREJSLlJPQ0hFLkNPTWFzdGVpbmZlbGShMTAvoAMCAQihKAQmCADwSRXiuHorXYmh UNvxq+HX/4j/dVSqr5vJ02anMGlZZnduCZcwV6AiMCCgAwIBAKEZBBdEQlIuUk9DSEUuQ09NYXN0Z WluZmVsZKExMC+gAwIBA6EoBCYIANEhS6vyfY9cpethqr64UZcf4XWMQFPYmvkrU6+qlWCnCqfKiD AzoTEwL6ADAgEBoSgEJggA6TGpzIElqIiEN+bgeZYSUJm5G/o3nORRyg1oAp8C1H35cyyVME2gGDA WoAMCAQWhDwQNREJSLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIACSVJDR+FFTCMrmWMcwwT4F47jxL LaAac0/gncsxU5+VR+jgfg== krbPasswordExpiration: 20130324201805Z krbLastPwdChange: 20120925201805Z krbExtraData:: AAJ9EWJQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA== mepManagedEntry: cn=asteinfeld,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=be53ab18-0820-11e2-9b0a-005056bb0010,cn=sudorules,cn=sud o,dc=dbr,dc=roche,dc=com memberOf: cn=tempsudo,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=00544f1a-17a6-11e2-8dde-005056bb0010,cn=sudorules,cn=sud o,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=9a7ec120-185e-11e2-891c-005056bb0010,cn=hbac,dc=dbr,dc=r oche,dc=com krbLoginFailedCount: 0 krbLastSuccessfulAuth: 20121017184614Z krbTicketFlags: 128 krbLastFailedAuth: 20121015143818Z [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password: dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com objectClass: posixAccount objectClass: top gecos: Jason Macklin cn: Jason Macklin uidNumber: 2084 gidNumber: 2084 loginShell: /bin/bash homeDirectory: /home2/jmacklin uid: jmacklin dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com displayName: Jason Macklin cn: Jason Macklin objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: mepOriginEntry loginShell: /bin/bash sn: Macklin gecos: Jason Macklin homeDirectory: /home2/jmacklin krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc =roche,dc=com krbPrincipalName: jmacklin at DBR.ROCHE.COM givenName: Jason uid: jmacklin initials: JM uidNumber: 2084 gidNumber: 2084 ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010 mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche, dc=com memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche ,dc=com memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro che,dc=com memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r oche,dc=com memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co m memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c om memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud o,dc=dbr,dc=roche,dc=com krbLastFailedAuth: 20121017164159Z krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny 37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv 8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb R5aBPg== krbLastPwdChange: 20120809140419Z krbPasswordExpiration: 20130205140419Z userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ= = krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA== krbLastSuccessfulAuth: 20121017184444Z krbLoginFailedCount: 0 krbTicketFlags: 128 So with all of that output, I would like to mention the discrepancy with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was problematic until I stumbled upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I have no sudo capabilities at all. -----Original Message----- From: Rich Megginson [mailto:rmeggins at redhat.com] Sent: Wednesday, October 17, 2012 2:06 PM To: Macklin, Jason {DASB~Branford} Cc: rcritten at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/17/2012 11:51 AM, Macklin, Jason wrote: > I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials" > > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? > Enter LDAP Password: > No such object (32) > > Working account returns same thing... > > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? > Enter LDAP Password: > No such object (32) Sorry, I though ipa would have configured your /etc/openldap/ldap.conf with your base dn. Try this: ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \* > > -----Original Message----- > From: Rob Crittenden [mailto:rcritten at redhat.com] > Sent: Wednesday, October 17, 2012 1:37 PM > To: Macklin, Jason {DASB~Branford} > Cc: rmeggins at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > Macklin, Jason wrote: >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> ldap_bind: Invalid credentials (49) >> >> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. > You use the password of the user you are binding as, in this case the directory manager. > > rob > >> -----Original Message----- >> From: Rich Megginson [mailto:rmeggins at redhat.com] >> Sent: Wednesday, October 17, 2012 1:15 PM >> To: Macklin, Jason {DASB~Branford} >> Cc: simo at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. >> >> On 10/17/2012 11:13 AM, Macklin, Jason wrote: >>> None of my users have an LDAP password being requested by running that command (except the admin user). >>> >>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >>> >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >> You have to specify which server to talk to using the -H ldap://fqdn.of.host option. >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users >> From dpal at redhat.com Wed Oct 17 18:57:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 14:57:11 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> Message-ID: <507EFF87.8090009@redhat.com> On 10/17/2012 01:05 PM, Macklin, Jason wrote: > Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me. > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > SASL username: admin at DBR.ROCHE.COM > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: ALL > # > > # sudoers, dbr.roche.com > dn: ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: extensibleObject > ou: sudoers > > # test4, sudoers, dbr.roche.com > dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: asteinfeld > sudoHost: dbduwdu062.dbr.roche.com > sudoHost: +tempsudo > sudoCommand: ALL > cn: test4 This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group. Is this the user you making tests with? Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured. Also HBAC should allow this user to authenticate via sudo on this host. AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too. > > # switch, sudoers, dbr.roche.com > dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: oyilmaz > sudoHost: dbdusdu071.dbr.roche.com > sudoCommand: /bin/su > cn: switch This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com" > > # jing144, sudoers, dbr.roche.com > dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: jli > sudoHost: dbduvdu144.dbr.roche.com > sudoCommand: ALL > cn: jing144 I hope you can now deduce the meaning of this one :-) > > # Admin, sudoers, dbr.roche.com > dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: jmacklin > sudoUser: mrini > sudoUser: cgajare > sudoUser: parnold > sudoUser: hhebert > sudoUser: ckuecherer > sudoUser: gferreri > sudoHost: ALL > sudoCommand: ALL > cn: Admin given users ALL commands on any host. > # search result > search: 4 > result: 0 Success > > # numResponses: 6 > # numEntries: 5 > > I really appreciate all of the help! > > Cheers, > Jason > So with this knowledge can you try different combinations of users and hosts and provide the results? You might want to remove the Admin for now to get it out of picture. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From jason.macklin at roche.com Wed Oct 17 19:05:15 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Wed, 17 Oct 2012 15:05:15 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507EFF87.8090009@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> <507EFF87.8090009@redhat.com> Message-ID: Yes Dmitri, this is the user I'm doing the tests with on that client. Though I would expect this user to have sudo capabilities on this host he does not. I first came across the idea that maybe domainname/nisdomainname/dnsdomainname did not match and that was causing the problem. I have since fixed all of those to match my system domain which is the same domain that the client was enrolled with and it did not change any of the sudo behaviors for this user. I currently have no specific HBAC rule configured besides the "wide open" rule. Do I need one more specific for allowing users to run sudo? -----Original Message----- From: Dmitri Pal [mailto:dpal at redhat.com] Sent: Wednesday, October 17, 2012 2:57 PM To: Macklin, Jason {DASB~Branford} Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. On 10/17/2012 01:05 PM, Macklin, Jason wrote: > Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me. > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" > SASL/GSSAPI authentication started > SASL username: admin at DBR.ROCHE.COM > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree # > filter: (objectclass=*) # requesting: ALL # > > # sudoers, dbr.roche.com > dn: ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: extensibleObject > ou: sudoers > > # test4, sudoers, dbr.roche.com > dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: asteinfeld > sudoHost: dbduwdu062.dbr.roche.com > sudoHost: +tempsudo > sudoCommand: ALL > cn: test4 This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group. Is this the user you making tests with? Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured. Also HBAC should allow this user to authenticate via sudo on this host. AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too. > > # switch, sudoers, dbr.roche.com > dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: oyilmaz > sudoHost: dbdusdu071.dbr.roche.com > sudoCommand: /bin/su > cn: switch This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com" > > # jing144, sudoers, dbr.roche.com > dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: jli > sudoHost: dbduvdu144.dbr.roche.com > sudoCommand: ALL > cn: jing144 I hope you can now deduce the meaning of this one :-) > > # Admin, sudoers, dbr.roche.com > dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com > objectClass: sudoRole > sudoUser: jmacklin > sudoUser: mrini > sudoUser: cgajare > sudoUser: parnold > sudoUser: hhebert > sudoUser: ckuecherer > sudoUser: gferreri > sudoHost: ALL > sudoCommand: ALL > cn: Admin given users ALL commands on any host. > # search result > search: 4 > result: 0 Success > > # numResponses: 6 > # numEntries: 5 > > I really appreciate all of the help! > > Cheers, > Jason > So with this knowledge can you try different combinations of users and hosts and provide the results? You might want to remove the Admin for now to get it out of picture. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Oct 17 19:17:43 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 15:17:43 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> Message-ID: <507F0457.50507@redhat.com> Bret Wortman wrote: > Now it appears that whatever is supposed to be running on port 9445 > (looks like mindarray-ca) isn't running, and I'm not sure how it gets > started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA > test box I first set up, and it's running on the test box but not the > new one. Where should I look next? See if there are any SELinux denials: ausearch -m AVC It looks like tomcat failed to start. The logs are in /var/log/pki-ca. rob > > On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman > > wrote: > > Spot on. It was a fresh install of F17 and I neglected to # yum > update first. I've done so, rebooted, and am trying again with > better results. > > > On Wed, Oct 17, 2012 at 1:45 PM, John Dennis > wrote: > > On 10/17/2012 12:40 PM, Bret Wortman wrote: > > I recently tried installing freeipa on a new server, but > ipa-server-install had problems around this point: > > Configuring certificate server: Estimated time 3 minutes 30 > seconds > [1/18]: creating certificate server user > [2/18]: creating pki-ca instance > [3/18]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > fs1.wedgeofli.me > -cs_port 9445 > > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user > admin > -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME > > -ldap_host fs1.wedgeofli.me > -ldap_port 7389 > > -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX > -base_dn o=ipaca > -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm > SHA256withRSA > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad > -token_name > internal -ca_subsystem_cert_subject___name CN=CA > Subsystem,O=WEDGEOFLI.ME > -ca_ocsp_cert_subject_name CN=OCSP > Subsystem,O=WEDGEOFLI.ME > > -ca_server_cert_subject_name CN=fs1.wedgeofli.me > > ,O=WE__DGEOFLI.ME > > -ca_audit_signing_cert___subject_name CN=CA > Audit,O=WEDGEOFLI.ME > -ca_sign_cert_subject_name CN=Certificate > Authority,O=WEDGEOFLI.ME > -external false -clone > > false' returned non-zero exit status 255 > Unexpected error - see ipaserver-install.log for details: > Configuration of CA failed > [root at fs1 ~]# > > The logfile revealed the following stack trace: > > ##############################__############### > Attempting to connect to: fs1.wedgeofli.me:9445 > > > > Exception in LoginPanel(): java.lang.NullPointerException > ERROR: ConfigureCA: LoginPanel() failure > ERROR: unable to create CA > > ##############################__##############################__########### > > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send > Request:java.net .__ConnectException: > Connection refused > java.net.ConnectException: Connection refused > at java.net.PlainSocketImpl.__socketConnect(Native Method) > at > java.net > .__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) > at > java.net > .__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) > at > java.net > .__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) > at > java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) > at java.net.Socket.connect(__Socket.java:579) > at java.net.Socket.connect(__Socket.java:528) > at java.net.Socket.(Socket.__java:425) > at java.net.Socket.(Socket.__java:241) > at HTTPClient.sslConnect(__HTTPClient.java:326) > at ConfigureCA.LoginPanel(__ConfigureCA.java:244) > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.__java:1672) > java.lang.NullPointerException > at ConfigureCA.LoginPanel(__ConfigureCA.java:245) > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) > at ConfigureCA.main(ConfigureCA.__java:1672) > > Now I seem to be stuck. I tried uninstalling the > freeipa-server package > with # yum remove freeipa-server and then reinstalled it the > same way, > but ipa-server-install won't run no matter what I attempt. > > Any thoughts? I'm pretty new to IPA. > > > There is a good chance this is due to a version mismatch between > the IPA packages and the dogtag packages. You didn't mention > which OS you're using nor the versions of the relevant packages, > that would have been helpful. In any event I would make sure all > your packages are up to date. > > > -- > John Dennis > > > > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From rmeggins at redhat.com Wed Oct 17 19:18:22 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 17 Oct 2012 13:18:22 -0600 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> <507EF371.8070804@redhat.com> Message-ID: <507F047E.60703@redhat.com> On 10/17/2012 12:49 PM, Macklin, Jason wrote: > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \* > > dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com ...snip... > krbPrincipalName: asteinfeld at DBR.ROCHE.COM > krbPasswordExpiration: 20130324201805Z > krbLastPwdChange: 20120925201805Z > krbLoginFailedCount: 0 > krbLastSuccessfulAuth: 20121017184614Z > krbTicketFlags: 128 > krbLastFailedAuth: 20121015143818Z No krbPwdLockoutDuration attribute - so according to ipalockout_preop() this means the "Entry permanently locked". Not sure why. > > [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password: > dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com > objectClass: posixAccount > objectClass: top > gecos: Jason Macklin > cn: Jason Macklin > uidNumber: 2084 > gidNumber: 2084 > loginShell: /bin/bash > homeDirectory: /home2/jmacklin > uid: jmacklin > > dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com > displayName: Jason Macklin > cn: Jason Macklin > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: mepOriginEntry > loginShell: /bin/bash > sn: Macklin > gecos: Jason Macklin > homeDirectory: /home2/jmacklin > krbPwdPolicyReference: cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc > =roche,dc=com > krbPrincipalName: jmacklin at DBR.ROCHE.COM > givenName: Jason > uid: jmacklin > initials: JM > uidNumber: 2084 > gidNumber: 2084 > ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010 > mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com > memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com > memberOf: cn=Replication Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche, > dc=com > memberOf: cn=Add Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche > ,dc=com > memberOf: cn=Modify Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro > che,dc=com > memberOf: cn=Remove Replication Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro > che,dc=com > memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com > memberOf: cn=Manage host keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com > memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com > memberOf: cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=dbr,dc=r > oche,dc=com > memberOf: cn=Unlock user accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co > m > memberOf: cn=Manage service keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c > om > memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com > memberOf: ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud > o,dc=dbr,dc=roche,dc=com > krbLastFailedAuth: 20121017164159Z > krbPrincipalKey:: MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX > BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a > sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl > IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny > 37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB > MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F > Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA > CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc > EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv > 8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA > wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS > gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ > SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb > R5aBPg== > krbLastPwdChange: 20120809140419Z > krbPasswordExpiration: 20130205140419Z > userPassword:: e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ= > = > krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA== > krbLastSuccessfulAuth: 20121017184444Z > krbLoginFailedCount: 0 > krbTicketFlags: 128 > > So with all of that output, I would like to mention the discrepancy with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was problematic until I stumbled upon a post that mentioned creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I have no sudo capabilities at all. > > -----Original Message----- > From: Rich Megginson [mailto:rmeggins at redhat.com] > Sent: Wednesday, October 17, 2012 2:06 PM > To: Macklin, Jason {DASB~Branford} > Cc: rcritten at redhat.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 11:51 AM, Macklin, Jason wrote: >> I assume that this iteration was with the correct credentials as it responds with something other then "Invalid Credentials" >> >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> No such object (32) >> >> Working account returns same thing... >> >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >> Enter LDAP Password: >> No such object (32) > Sorry, I though ipa would have configured your /etc/openldap/ldap.conf with your base dn. Try this: > > ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \* >> -----Original Message----- >> From: Rob Crittenden [mailto:rcritten at redhat.com] >> Sent: Wednesday, October 17, 2012 1:37 PM >> To: Macklin, Jason {DASB~Branford} >> Cc: rmeggins at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. >> >> Macklin, Jason wrote: >>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> ldap_bind: Invalid credentials (49) >>> >>> I know this user password because I reset it for the purpose of troubleshooting this issue with that account. I also get the same response when I use the admin account of my own account. >> You use the password of the user you are binding as, in this case the directory manager. >> >> rob >> >>> -----Original Message----- >>> From: Rich Megginson [mailto:rmeggins at redhat.com] >>> Sent: Wednesday, October 17, 2012 1:15 PM >>> To: Macklin, Jason {DASB~Branford} >>> Cc: simo at redhat.com; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. >>> >>> On 10/17/2012 11:13 AM, Macklin, Jason wrote: >>>> None of my users have an LDAP password being requested by running that command (except the admin user). >>>> >>>> Does each user account require an ldap account to go along with their login account? I just get the following over and over no matter which account I switch in the command... >>>> >>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=admin \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>> You have to specify which server to talk to using the -H ldap://fqdn.of.host option. >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >>> From dpal at redhat.com Wed Oct 17 19:26:03 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 17 Oct 2012 15:26:03 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> <507EFF87.8090009@redhat.com> Message-ID: <507F064B.6050200@redhat.com> On 10/17/2012 03:05 PM, Macklin, Jason wrote: > Yes Dmitri, this is the user I'm doing the tests with on that client. Though I would expect this user to have sudo capabilities on this host he does not. I first came across the idea that maybe domainname/nisdomainname/dnsdomainname did not match and that was causing the problem. I have since fixed all of those to match my system domain which is the same domain that the client was enrolled with and it did not change any of the sudo behaviors for this user. I currently have no specific HBAC rule configured besides the "wide open" rule. Do I need one more specific for allowing users to run sudo? No. It should just work then. It definitely connects and matches the Admin rule but not the other rules so I was not sure if you are testing the right rule on the right machine with the right user. We can start dealing with the problems step by step. We know Admin rule works. If you add all hosts to a hostgroup and use it in the Admin rule instead of just all would it continue to work? Then you can start removing hosts from the group one by one. After testing with group you can replace the group with individual host and see whether it works and so on. May be there is a bug somewhere but so far we have not narrowed it done well enough. I am traveling next day so I hope someone else will pickup the thread. > > -----Original Message----- > From: Dmitri Pal [mailto:dpal at redhat.com] > Sent: Wednesday, October 17, 2012 2:57 PM > To: Macklin, Jason {DASB~Branford} > Cc: JR.Aquino at citrix.com; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. > > On 10/17/2012 01:05 PM, Macklin, Jason wrote: >> Thanks guys! Adding the "-b" did make a world of difference though it still doesn't make anything too obvious... at least to me. >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -Y GSSAPI -H ldap://dbduvdu145.dbr.roche.com -b "ou=SUDOers,dc=dbr,dc=roche,dc=com" >> SASL/GSSAPI authentication started >> SASL username: admin at DBR.ROCHE.COM >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree # >> filter: (objectclass=*) # requesting: ALL # >> >> # sudoers, dbr.roche.com >> dn: ou=sudoers,dc=dbr,dc=roche,dc=com >> objectClass: extensibleObject >> ou: sudoers >> >> # test4, sudoers, dbr.roche.com >> dn: cn=test4,ou=sudoers,dc=dbr,dc=roche,dc=com >> objectClass: sudoRole >> sudoUser: asteinfeld >> sudoHost: dbduwdu062.dbr.roche.com >> sudoHost: +tempsudo >> sudoCommand: ALL >> cn: test4 > This means that user "asteinfeld" should be allowed to execute any command on host "dbduwdu062.dbr.roche.com" or any host that is a member of the "tempsudo" host group. > Is this the user you making tests with? > > Keep in mind the other general per-requisits: If you use netgroups the domain should be correct and the netgroups should be configured. > Also HBAC should allow this user to authenticate via sudo on this host. > AFAIR your HBAC is now wide open but when you start changing things to narrow access you need to make HBAC rules for SUDO too. >> # switch, sudoers, dbr.roche.com >> dn: cn=switch,ou=sudoers,dc=dbr,dc=roche,dc=com >> objectClass: sudoRole >> sudoUser: oyilmaz >> sudoHost: dbdusdu071.dbr.roche.com >> sudoCommand: /bin/su >> cn: switch > This rule allows "oyilmaz" to execute one command "/bin/su" on host "dbdusdu071.dbr.roche.com" >> # jing144, sudoers, dbr.roche.com >> dn: cn=jing144,ou=sudoers,dc=dbr,dc=roche,dc=com >> objectClass: sudoRole >> sudoUser: jli >> sudoHost: dbduvdu144.dbr.roche.com >> sudoCommand: ALL >> cn: jing144 > I hope you can now deduce the meaning of this one :-) > >> # Admin, sudoers, dbr.roche.com >> dn: cn=Admin,ou=sudoers,dc=dbr,dc=roche,dc=com >> objectClass: sudoRole >> sudoUser: jmacklin >> sudoUser: mrini >> sudoUser: cgajare >> sudoUser: parnold >> sudoUser: hhebert >> sudoUser: ckuecherer >> sudoUser: gferreri >> sudoHost: ALL >> sudoCommand: ALL >> cn: Admin > given users ALL commands on any host. > >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 6 >> # numEntries: 5 >> >> I really appreciate all of the help! >> >> Cheers, >> Jason >> > So with this knowledge can you try different combinations of users and hosts and provide the results? > You might want to remove the Admin for now to get it out of picture. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager for IdM portfolio Red Hat Inc. > > > ------------------------------- > Looking to carve out IT costs? > www.redhat.com/carveoutcosts/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From rcritten at redhat.com Wed Oct 17 19:26:41 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 15:26:41 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507F047E.60703@redhat.com> References: <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> , <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> <507EF371.8070804@redhat.com> <507F047E.60703@redhat.c! om> Message-ID: <507F0671.9020403@redhat.com> Rich Megginson wrote: > On 10/17/2012 12:49 PM, Macklin, Jason wrote: >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory >> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \* > >> >> dn: uid=asteinfeld,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com > ...snip... >> krbPrincipalName: asteinfeld at DBR.ROCHE.COM >> krbPasswordExpiration: 20130324201805Z >> krbLastPwdChange: 20120925201805Z >> krbLoginFailedCount: 0 >> krbLastSuccessfulAuth: 20121017184614Z >> krbTicketFlags: 128 >> krbLastFailedAuth: 20121015143818Z > > No krbPwdLockoutDuration attribute - so according to ipalockout_preop() > this means the "Entry permanently locked". Not sure why. I don't believe this applies if the attribute doesn't exist. It doesn't for any of my test users and it works fine. >> >> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -H >> ldap://dbduvdu145.dbr.roche.com -D "cn=directory manager" -W -b >> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password: >> dn: uid=jmacklin,cn=users,cn=compat,dc=dbr,dc=roche,dc=com >> objectClass: posixAccount >> objectClass: top >> gecos: Jason Macklin >> cn: Jason Macklin >> uidNumber: 2084 >> gidNumber: 2084 >> loginShell: /bin/bash >> homeDirectory: /home2/jmacklin >> uid: jmacklin >> >> dn: uid=jmacklin,cn=users,cn=accounts,dc=dbr,dc=roche,dc=com >> displayName: Jason Macklin >> cn: Jason Macklin >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: mepOriginEntry >> loginShell: /bin/bash >> sn: Macklin >> gecos: Jason Macklin >> homeDirectory: /home2/jmacklin >> krbPwdPolicyReference: >> cn=global_policy,cn=DBR.ROCHE.COM,cn=kerberos,dc=dbr,dc >> =roche,dc=com >> krbPrincipalName: jmacklin at DBR.ROCHE.COM >> givenName: Jason >> uid: jmacklin >> initials: JM >> uidNumber: 2084 >> gidNumber: 2084 >> ipaUniqueID: 045652b4-8e3c-11e1-831f-005056bb0010 >> mepManagedEntry: cn=jmacklin,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com >> memberOf: cn=admins,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com >> memberOf: cn=Replication >> Administrators,cn=privileges,cn=pbac,dc=dbr,dc=roche, >> dc=com >> memberOf: cn=Add Replication >> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=roche >> ,dc=com >> memberOf: cn=Modify Replication >> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro >> che,dc=com >> memberOf: cn=Remove Replication >> Agreements,cn=permissions,cn=pbac,dc=dbr,dc=ro >> che,dc=com >> memberOf: cn=Host Enrollment,cn=privileges,cn=pbac,dc=dbr,dc=roche,dc=com >> memberOf: cn=Manage host >> keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com >> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=com >> memberOf: cn=Add krbPrincipalName to a >> host,cn=permissions,cn=pbac,dc=dbr,dc=r >> oche,dc=com >> memberOf: cn=Unlock user >> accounts,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=co >> m >> memberOf: cn=Manage service >> keytab,cn=permissions,cn=pbac,dc=dbr,dc=roche,dc=c >> om >> memberOf: cn=dbr,cn=groups,cn=accounts,dc=dbr,dc=roche,dc=com >> memberOf: >> ipaUniqueID=23216c12-9934-11e1-bd4c-005056bb0010,cn=sudorules,cn=sud >> o,dc=dbr,dc=roche,dc=com >> krbLastFailedAuth: 20121017164159Z >> krbPrincipalKey:: >> MIIC4qADAgEBoQMCAQGiAwIBBaMDAgEBpIICyjCCAsYwbaAgMB6gAwIBAKEX >> >> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hSTBHoAMCARKhQAQ+IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a >> >> >> sC2QJFL/lnbaFO1DYG15WjJYXnJ7k3m0LN0aTyjvz7FN4OWMF4tvvowXaAgMB6gAwIBAKEXBBVEQl >> >> >> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARGhMAQuEAD6UdNSe/mp8qqi4OuT7HOqIs80DFQDRny >> >> >> 37aZaD4lYrFsnQiBtpnpMnNSxADBloCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqFB >> >> >> MD+gAwIBEKE4BDYYADAQZLDW61U+4aEZT4b+/X/OpiQLHTQlyIUolm9EjVG4wXu+8Mn4lMYMZyR/F >> >> >> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBVEQlIuUk9DSEUuQ09Nam1hY2tsaW6hOTA3oAMCARehMAQuEA >> >> >> CiWDGd28XkiaDAwpGyK0MqSawLCXs+jKOFAA5BoSpayVTJJqjzAwSEitSu5zBVoCAwHqADAgEAoRc >> >> >> EFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gAwIBCKEoBCYIAKL5bzV4nQide/+6/2FE5LxYGULv >> >> >> 8Ws/Uu0RXrwAnR8/ZuUh0TBVoCAwHqADAgEAoRcEFURCUi5ST0NIRS5DT01qbWFja2xpbqExMC+gA >> >> >> wIBA6EoBCYIANgV0agxRmfBwY2Cb7gPlm1oWDY5qhZidd8a0KmeIlBG56XLZjAzoTEwL6ADAgEBoS >> >> >> gEJggAo/BQC7g4SWQY0UkU7rvoOAXwobVlAZn8mesgQEznRDr2+bxjME2gGDAWoAMCAQWhDwQNREJ >> >> >> SLlJPQ0hFLkNPTaExMC+gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+Lzs0Ulxgf4FDEnTRXTjfJBqXIJb >> >> R5aBPg== >> krbLastPwdChange: 20120809140419Z >> krbPasswordExpiration: 20130205140419Z >> userPassword:: >> e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVVF4VTdJLzh1TXREVnBWZjlnMWRxa0E9PQ= >> = >> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSEUuQ09NAA== >> krbLastSuccessfulAuth: 20121017184444Z >> krbLoginFailedCount: 0 >> krbTicketFlags: 128 >> >> So with all of that output, I would like to mention the discrepancy >> with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was >> problematic until I stumbled upon a post that mentioned >> creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or >> /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I >> have no sudo capabilities at all. >> >> -----Original Message----- >> From: Rich Megginson [mailto:rmeggins at redhat.com] >> Sent: Wednesday, October 17, 2012 2:06 PM >> To: Macklin, Jason {DASB~Branford} >> Cc: rcritten at redhat.com; freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a >> per command or host level. >> >> On 10/17/2012 11:51 AM, Macklin, Jason wrote: >>> I assume that this iteration was with the correct credentials as it >>> responds with something other then "Invalid Credentials" >>> >>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory >>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> No such object (32) >>> >>> Working account returns same thing... >>> >>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory >>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>> Enter LDAP Password: >>> No such object (32) >> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf >> with your base dn. Try this: >> >> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory >> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \* >>> -----Original Message----- >>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>> Sent: Wednesday, October 17, 2012 1:37 PM >>> To: Macklin, Jason {DASB~Branford} >>> Cc: rmeggins at redhat.com; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a >>> per command or host level. >>> >>> Macklin, Jason wrote: >>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.com -D "cn=directory >>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> ldap_bind: Invalid credentials (49) >>>> >>>> I know this user password because I reset it for the purpose of >>>> troubleshooting this issue with that account. I also get the same >>>> response when I use the admin account of my own account. >>> You use the password of the user you are binding as, in this case the >>> directory manager. >>> >>> rob >>> >>>> -----Original Message----- >>>> From: Rich Megginson [mailto:rmeggins at redhat.com] >>>> Sent: Wednesday, October 17, 2012 1:15 PM >>>> To: Macklin, Jason {DASB~Branford} >>>> Cc: simo at redhat.com; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on >>>> a per command or host level. >>>> >>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote: >>>>> None of my users have an LDAP password being requested by running >>>>> that command (except the admin user). >>>>> >>>>> Does each user account require an ldap account to go along with >>>>> their login account? I just get the following over and over no >>>>> matter which account I switch in the command... >>>>> >>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>> manager" -W uid=admin \* krbPwdLockoutDuration ? >>>>> Enter LDAP Password: >>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>>> Enter LDAP Password: >>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>>>> Enter LDAP Password: >>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>> You have to specify which server to talk to using the -H >>>> ldap://fqdn.of.host option. >>>> >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> > From rcritten at redhat.com Wed Oct 17 19:44:12 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 17 Oct 2012 15:44:12 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> <507EFF87.8090009@redhat.com> Message-ID: <507F0A8C.2020006@redhat.com> Can you confirm that you have sudoer_debug set to 2? If I gather correctly, this is on RHEL 6.3? What version of sudo? I'm seeing different output. Mine includes the number of candidate results for sudoUser are found. If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server you'll be able to see the LDAP searches the sudo client is making. The log is buffered so you won't see them immediately. Can you send us the queries that are being made? thanks rob From toastedpenguininfo at gmail.com Wed Oct 17 19:53:27 2012 From: toastedpenguininfo at gmail.com (Toasted Penguin) Date: Wed, 17 Oct 2012 14:53:27 -0500 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507F0671.9020403@redhat.com> References: <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com> <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED463.8020406@redhat.com> <1350492419.30610.47.camel@willson.li.ssimo.org> <507EE2B8.6020402@redhat.com> <507EE79A.5000705@redhat.com> <507EECCF.3090508@redhat.com> <507EF371.8070804@redhat.com> <507F047E.60703@redhat.com> <507F0671.9020403@redhat.com> Message-ID: On Wed, Oct 17, 2012 at 2:26 PM, Rob Crittenden wrote: > Rich Megginson wrote: > >> On 10/17/2012 12:49 PM, Macklin, Jason wrote: >> >>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com-D "cn=directory >>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=asteinfeld \* >>> >> >> >>> >>> dn: uid=asteinfeld,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com >>> >> ...snip... >> >>> krbPrincipalName: asteinfeld at DBR.ROCHE.COM >>> krbPasswordExpiration: 20130324201805Z >>> krbLastPwdChange: 20120925201805Z >>> krbLoginFailedCount: 0 >>> krbLastSuccessfulAuth: 20121017184614Z >>> krbTicketFlags: 128 >>> krbLastFailedAuth: 20121015143818Z >>> >> >> No krbPwdLockoutDuration attribute - so according to ipalockout_preop() >> this means the "Entry permanently locked". Not sure why. >> > > I don't believe this applies if the attribute doesn't exist. It doesn't > for any of my test users and it works fine. > > > >>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -H >>> ldap://dbduvdu145.dbr.roche.**com -D >>> "cn=directory manager" -W -b >>> "dc=dbr,dc=roche,dc=com" uid=jmacklin \*Enter LDAP Password: >>> dn: uid=jmacklin,cn=users,cn=**compat,dc=dbr,dc=roche,dc=com >>> objectClass: posixAccount >>> objectClass: top >>> gecos: Jason Macklin >>> cn: Jason Macklin >>> uidNumber: 2084 >>> gidNumber: 2084 >>> loginShell: /bin/bash >>> homeDirectory: /home2/jmacklin >>> uid: jmacklin >>> >>> dn: uid=jmacklin,cn=users,cn=**accounts,dc=dbr,dc=roche,dc=**com >>> displayName: Jason Macklin >>> cn: Jason Macklin >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalperson >>> objectClass: inetorgperson >>> objectClass: inetuser >>> objectClass: posixaccount >>> objectClass: krbprincipalaux >>> objectClass: krbticketpolicyaux >>> objectClass: ipaobject >>> objectClass: mepOriginEntry >>> loginShell: /bin/bash >>> sn: Macklin >>> gecos: Jason Macklin >>> homeDirectory: /home2/jmacklin >>> krbPwdPolicyReference: >>> cn=global_policy,cn=DBR.ROCHE.**COM >>> ,cn=kerberos,dc=dbr,dc >>> =roche,dc=com >>> krbPrincipalName: jmacklin at DBR.ROCHE.COM >>> givenName: Jason >>> uid: jmacklin >>> initials: JM >>> uidNumber: 2084 >>> gidNumber: 2084 >>> ipaUniqueID: 045652b4-8e3c-11e1-831f-**005056bb0010 >>> mepManagedEntry: cn=jmacklin,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc= >>> **com >>> memberOf: cn=admins,cn=groups,cn=**accounts,dc=dbr,dc=roche,dc=**com >>> memberOf: cn=Replication >>> Administrators,cn=privileges,**cn=pbac,dc=dbr,dc=roche, >>> dc=com >>> memberOf: cn=Add Replication >>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=roche >>> ,dc=com >>> memberOf: cn=Modify Replication >>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro >>> che,dc=com >>> memberOf: cn=Remove Replication >>> Agreements,cn=permissions,cn=**pbac,dc=dbr,dc=ro >>> che,dc=com >>> memberOf: cn=Host Enrollment,cn=privileges,cn=** >>> pbac,dc=dbr,dc=roche,dc=com >>> memberOf: cn=Manage host >>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=com >>> memberOf: cn=Enroll a host,cn=permissions,cn=pbac,** >>> dc=dbr,dc=roche,dc=com >>> memberOf: cn=Add krbPrincipalName to a >>> host,cn=permissions,cn=pbac,**dc=dbr,dc=r >>> oche,dc=com >>> memberOf: cn=Unlock user >>> accounts,cn=permissions,cn=**pbac,dc=dbr,dc=roche,dc=co >>> m >>> memberOf: cn=Manage service >>> keytab,cn=permissions,cn=pbac,**dc=dbr,dc=roche,dc=c >>> om >>> memberOf: cn=dbr,cn=groups,cn=accounts,**dc=dbr,dc=roche,dc=com >>> memberOf: >>> ipaUniqueID=23216c12-9934-**11e1-bd4c-005056bb0010,cn=**sudorules,cn=sud >>> o,dc=dbr,dc=roche,dc=com >>> krbLastFailedAuth: 20121017164159Z >>> krbPrincipalKey:: >>> MIIC4qADAgEBoQMCAQGiAwIBBaMDAg**EBpIICyjCCAsYwbaAgMB6gAwIBAKEX >>> >>> BBVEQlIuUk9DSEUuQ09Nam1hY2tsaW**6hSTBHoAMCARKhQAQ+** >>> IACOG0H0Ebd8nSSY6zU3Y29ZHtQ9a >>> >>> >>> sC2QJFL/**lnbaFO1DYG15WjJYXnJ7k3m0LN0aTy**jvz7FN4OWMF4tvvowXaAgMB6gAwIBA >>> **KEXBBVEQl >>> >>> >>> IuUk9DSEUuQ09Nam1hY2tsaW6hOTA3**oAMCARGhMAQuEAD6UdNSe/** >>> mp8qqi4OuT7HOqIs80DFQDRny >>> >>> >>> 37aZaD4lYrFsnQiBtpnpMnNSxADBlo**CAwHqADAgEAoRcEFURCUi5ST0NIRS5** >>> DT01qbWFja2xpbqFB >>> >>> >>> MD+gAwIBEKE4BDYYADAQZLDW61U+**4aEZT4b+/X/**OpiQLHTQlyIUolm9EjVG4wXu+** >>> 8Mn4lMYMZyR/F >>> >>> >>> Gw6NWeeq1kwXaAgMB6gAwIBAKEXBBV**EQlIuUk9DSEUuQ09Nam1hY2tsaW6hO** >>> TA3oAMCARehMAQuEA >>> >>> >>> CiWDGd28XkiaDAwpGyK0MqSawLCXs+**jKOFAA5BoSpayVTJJqjzAwSEitSu5z** >>> BVoCAwHqADAgEAoRc >>> >>> >>> EFURCUi5ST0NIRS5DT01qbWFja2xpb**qExMC+**gAwIBCKEoBCYIAKL5bzV4nQide/+6/** >>> 2FE5LxYGULv >>> >>> >>> 8Ws/Uu0RXrwAnR8/**ZuUh0TBVoCAwHqADAgEAoRcEFURCUi** >>> 5ST0NIRS5DT01qbWFja2xpbqExMC+**gA >>> >>> >>> wIBA6EoBCYIANgV0agxRmfBwY2Cb7g**Plm1oWDY5qhZidd8a0KmeIlBG56XLZ** >>> jAzoTEwL6ADAgEBoS >>> >>> >>> gEJggAo/**BQC7g4SWQY0UkU7rvoOAXwobVlAZn8**mesgQEznRDr2+** >>> bxjME2gGDAWoAMCAQWhDwQNREJ >>> >>> >>> SLlJPQ0hFLkNPTaExMC+**gAwIBAaEoBCYIAMDDcwjYU6jLJTnE+** >>> Lzs0Ulxgf4FDEnTRXTjfJBqXIJb >>> >>> R5aBPg== >>> krbLastPwdChange: 20120809140419Z >>> krbPasswordExpiration: 20130205140419Z >>> userPassword:: >>> e1NTSEF9a0NXcUxTc1JOQ2tEUVlLVV**F4VTdJLzh1TXREVnBWZjlnMWRxa0E9**PQ= >>> = >>> krbExtraData:: AAJjwyNQa2FkbWluZEBEQlIuUk9DSE**UuQ09NAA== >>> krbLastSuccessfulAuth: 20121017184444Z >>> krbLoginFailedCount: 0 >>> krbTicketFlags: 128 >>> >>> So with all of that output, I would like to mention the discrepancy >>> with ldap.conf. Just trying to get any "sudo" working on RHEL 6.3 was >>> problematic until I stumbled upon a post that mentioned >>> creating/editing /etc/sudo-ldap.conf rather then /etc/ldap.conf or >>> /etc/openldap/ldap.conf. If I remove the /etc/sudo-ldap.conf then I >>> have no sudo capabilities at all. >>> >>> -----Original Message----- >>> From: Rich Megginson [mailto:rmeggins at redhat.com] >>> Sent: Wednesday, October 17, 2012 2:06 PM >>> To: Macklin, Jason {DASB~Branford} >>> Cc: rcritten at redhat.com; freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a >>> per command or host level. >>> >>> On 10/17/2012 11:51 AM, Macklin, Jason wrote: >>> >>>> I assume that this iteration was with the correct credentials as it >>>> responds with something other then "Invalid Credentials" >>>> >>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com-D "cn=directory >>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> No such object (32) >>>> >>>> Working account returns same thing... >>>> >>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com-D "cn=directory >>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>>> Enter LDAP Password: >>>> No such object (32) >>>> >>> Sorry, I though ipa would have configured your /etc/openldap/ldap.conf >>> with your base dn. Try this: >>> >>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com-D "cn=directory >>> manager" -W -b "dc=dbr,dc=roche,dc=com" uid=jmacklin \* >>> >>>> -----Original Message----- >>>> From: Rob Crittenden [mailto:rcritten at redhat.com] >>>> Sent: Wednesday, October 17, 2012 1:37 PM >>>> To: Macklin, Jason {DASB~Branford} >>>> Cc: rmeggins at redhat.com; freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on a >>>> per command or host level. >>>> >>>> Macklin, Jason wrote: >>>> >>>>> ldapsearch -xLLL -H ldap://dbduvdu145.dbr.roche.**com-D "cn=directory >>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>>> Enter LDAP Password: >>>>> ldap_bind: Invalid credentials (49) >>>>> >>>>> I know this user password because I reset it for the purpose of >>>>> troubleshooting this issue with that account. I also get the same >>>>> response when I use the admin account of my own account. >>>>> >>>> You use the password of the user you are binding as, in this case the >>>> directory manager. >>>> >>>> rob >>>> >>>> -----Original Message----- >>>>> From: Rich Megginson [mailto:rmeggins at redhat.com] >>>>> Sent: Wednesday, October 17, 2012 1:15 PM >>>>> To: Macklin, Jason {DASB~Branford} >>>>> Cc: simo at redhat.com; freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] Sudo works for full access, but not on >>>>> a per command or host level. >>>>> >>>>> On 10/17/2012 11:13 AM, Macklin, Jason wrote: >>>>> >>>>>> None of my users have an LDAP password being requested by running >>>>>> that command (except the admin user). >>>>>> >>>>>> Does each user account require an ldap account to go along with >>>>>> their login account? I just get the following over and over no >>>>>> matter which account I switch in the command... >>>>>> >>>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>>> manager" -W uid=admin \* krbPwdLockoutDuration ? >>>>>> Enter LDAP Password: >>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>>> manager" -W uid=asteinfeld \* krbPwdLockoutDuration ? >>>>>> Enter LDAP Password: >>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> [jmacklin at dbduwdu062 Desktop]$ ldapsearch -xLLL -D "cn=directory >>>>>> manager" -W uid=jmacklin \* krbPwdLockoutDuration ? >>>>>> Enter LDAP Password: >>>>>> ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) >>>>>> >>>>> You have to specify which server to talk to using the -H >>>>> ldap://fqdn.of.host option. >>>>> >>>>> ______________________________**_________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/**mailman/listinfo/freeipa-users >>>>> >>>>> >> > ______________________________**_________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/**mailman/listinfo/freeipa-users > In case there is a bug I wanted to throw my hat in the ring because I am having almost the same exact issue with my deployment of sudo. I setup a sudo rule on the ipa server with a single sudo command (/bin/su), for all hosts, for a specific usergroup (netops). DIdn't work for my netops user. When I eliminated the specific sudo command and went for all sudo commands it started to work for my netops user. So I decided to add a few more hosts to test. However now with the 2 additional host no sudo commands work on either of these two hosts. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Oct 17 22:26:30 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 17 Oct 2012 18:26:30 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <507F0457.50507@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> Message-ID: I think I have SELinux turned off but will double-check in the morning. And reply to the list.... -- Bret Wortman http://bretwortman.com/ http://twitter.com/bretwortman On Wednesday, October 17, 2012 at 3:17 PM, Rob Crittenden wrote: > Bret Wortman wrote: > > Now it appears that whatever is supposed to be running on port 9445 > > (looks like mindarray-ca) isn't running, and I'm not sure how it gets > > started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA > > test box I first set up, and it's running on the test box but not the > > new one. Where should I look next? > > > > > See if there are any SELinux denials: ausearch -m AVC > > It looks like tomcat failed to start. The logs are in /var/log/pki-ca. > > rob > > > > > On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman > > > wrote: > > > > Spot on. It was a fresh install of F17 and I neglected to # yum > > update first. I've done so, rebooted, and am trying again with > > better results. > > > > > > On Wed, Oct 17, 2012 at 1:45 PM, John Dennis > > wrote: > > > > On 10/17/2012 12:40 PM, Bret Wortman wrote: > > > > I recently tried installing freeipa on a new server, but > > ipa-server-install had problems around this point: > > > > Configuring certificate server: Estimated time 3 minutes 30 > > seconds > > [1/18]: creating certificate server user > > [2/18]: creating pki-ca instance > > [3/18]: configuring certificate server instance > > ipa : CRITICAL failed to configure ca instance Command > > '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname > > fs1.wedgeofli.me > > -cs_port 9445 > > > > -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX > > -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user > > admin > > -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name > > ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa > > -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME > > > > -ldap_host fs1.wedgeofli.me > > -ldap_port 7389 > > > > -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX > > -base_dn o=ipaca > > -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm > > SHA256withRSA > > -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad > > -token_name > > internal -ca_subsystem_cert_subject___name CN=CA > > Subsystem,O=WEDGEOFLI.ME > > -ca_ocsp_cert_subject_name CN=OCSP > > Subsystem,O=WEDGEOFLI.ME > > > > -ca_server_cert_subject_name CN=fs1.wedgeofli.me > > > > ,O=WE__DGEOFLI.ME > > > > -ca_audit_signing_cert___subject_name CN=CA > > Audit,O=WEDGEOFLI.ME > > -ca_sign_cert_subject_name CN=Certificate > > Authority,O=WEDGEOFLI.ME > > -external false -clone > > > > false' returned non-zero exit status 255 > > Unexpected error - see ipaserver-install.log for details: > > Configuration of CA failed > > [root at fs1 ~]# > > > > The logfile revealed the following stack trace: > > > > ##############################__############### > > Attempting to connect to: fs1.wedgeofli.me:9445 > > > > > > > > Exception in LoginPanel(): java.lang.NullPointerException > > ERROR: ConfigureCA: LoginPanel() failure > > ERROR: unable to create CA > > > > ##############################__##############################__########### > > > > 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send > > Request:java.net .__ConnectException: > > Connection refused > > java.net.ConnectException: Connection refused > > at java.net.PlainSocketImpl.__socketConnect(Native Method) > > at > > java.net > > .__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) > > at > > java.net > > .__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) > > at > > java.net > > .__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) > > at > > java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) > > at java.net.Socket.connect(__Socket.java:579) > > at java.net.Socket.connect(__Socket.java:528) > > at java.net.Socket.(Socket.__java:425) > > at java.net.Socket.(Socket.__java:241) > > at HTTPClient.sslConnect(__HTTPClient.java:326) > > at ConfigureCA.LoginPanel(__ConfigureCA.java:244) > > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) > > at ConfigureCA.main(ConfigureCA.__java:1672) > > java.lang.NullPointerException > > at ConfigureCA.LoginPanel(__ConfigureCA.java:245) > > at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) > > at ConfigureCA.main(ConfigureCA.__java:1672) > > > > Now I seem to be stuck. I tried uninstalling the > > freeipa-server package > > with # yum remove freeipa-server and then reinstalled it the > > same way, > > but ipa-server-install won't run no matter what I attempt. > > > > Any thoughts? I'm pretty new to IPA. > > > > > > There is a good chance this is due to a version mismatch between > > the IPA packages and the dogtag packages. You didn't mention > > which OS you're using nor the versions of the relevant packages, > > that would have been helpful. In any event I would make sure all > > your packages are up to date. > > > > > > -- > > John Dennis > > > > > > > Looking to carve out IT costs? > > www.redhat.com/carveoutcosts/ > > > > > > > > > > -- > > Bret Wortman > > The Damascus Group > > Fairfax, VA > > http://bretwortman.com/ > > http://twitter.com/BretWortman > > > > > > > > > > -- > > Bret Wortman > > The Damascus Group > > Fairfax, VA > > http://bretwortman.com/ > > http://twitter.com/BretWortman > > > > > > > > _______________________________________________ > > Freeipa-users mailing list > > Freeipa-users at redhat.com > > https://www.redhat.com/mailman/listinfo/freeipa-users > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Oct 18 08:49:48 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 10:49:48 +0200 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> Message-ID: <507FC2AC.805@redhat.com> Hello Bret, This may be a long shot, but when I sometimes hit this kind of errors when CA installation crashed and there is still some remaining CA configuration (in /var/lib/pki-ca). I usually fix this with standard "ipa-server-install --uninstall -U" and then running this command: /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force HTH, Martin On 10/18/2012 12:26 AM, Bret Wortman wrote: > I think I have SELinux turned off but will double-check in the morning. And > reply to the list.... > > > -- > Bret Wortman > http://bretwortman.com/ > http://twitter.com/bretwortman > > On Wednesday, October 17, 2012 at 3:17 PM, Rob Crittenden wrote: > >> Bret Wortman wrote: >>> Now it appears that whatever is supposed to be running on port 9445 >>> (looks like mindarray-ca) isn't running, and I'm not sure how it gets >>> started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA >>> test box I first set up, and it's running on the test box but not the >>> new one. Where should I look next? >> >> See if there are any SELinux denials: ausearch -m AVC >> >> It looks like tomcat failed to start. The logs are in /var/log/pki-ca. >> >> rob >> >>> >>> On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman >>> > wrote: >>> >>> Spot on. It was a fresh install of F17 and I neglected to # yum >>> update first. I've done so, rebooted, and am trying again with >>> better results. >>> >>> >>> On Wed, Oct 17, 2012 at 1:45 PM, John Dennis >> > wrote: >>> >>> On 10/17/2012 12:40 PM, Bret Wortman wrote: >>> >>> I recently tried installing freeipa on a new server, but >>> ipa-server-install had problems around this point: >>> >>> Configuring certificate server: Estimated time 3 minutes 30 >>> seconds >>> [1/18]: creating certificate server user >>> [2/18]: creating pki-ca instance >>> [3/18]: configuring certificate server instance >>> ipa : CRITICAL failed to configure ca instance Command >>> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >>> fs1.wedgeofli.me >>> -cs_port 9445 >>> >>> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX >>> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user >>> admin >>> -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX -agent_name >>> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa >>> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME >>> >>> -ldap_host fs1.wedgeofli.me >>> -ldap_port 7389 >>> >>> -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX >>> -base_dn o=ipaca >>> -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm >>> SHA256withRSA >>> -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad >>> -token_name >>> internal -ca_subsystem_cert_subject___name CN=CA >>> Subsystem,O=WEDGEOFLI.ME >>> -ca_ocsp_cert_subject_name CN=OCSP >>> Subsystem,O=WEDGEOFLI.ME >>> >>> -ca_server_cert_subject_name CN=fs1.wedgeofli.me >>> >>> ,O=WE__DGEOFLI.ME >>> >>> -ca_audit_signing_cert___subject_name CN=CA >>> Audit,O=WEDGEOFLI.ME >>> -ca_sign_cert_subject_name CN=Certificate >>> Authority,O=WEDGEOFLI.ME >>> -external false -clone >>> >>> false' returned non-zero exit status 255 >>> Unexpected error - see ipaserver-install.log for details: >>> Configuration of CA failed >>> [root at fs1 ~]# >>> >>> The logfile revealed the following stack trace: >>> >>> ##############################__############### >>> Attempting to connect to: fs1.wedgeofli.me:9445 >>> >>> >>> >>> Exception in LoginPanel(): java.lang.NullPointerException >>> ERROR: ConfigureCA: LoginPanel() failure >>> ERROR: unable to create CA >>> >>> ##############################__##############################__########### >>> >>> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send >>> Request:java.net .__ConnectException: >>> Connection refused >>> java.net.ConnectException: Connection refused >>> at java.net.PlainSocketImpl.__socketConnect(Native Method) >>> at >>> java.net >>> .__AbstractPlainSocketImpl.__doConnect(__AbstractPlainSocketImpl.java:__339) >>> at >>> java.net >>> .__AbstractPlainSocketImpl.__connectToAddress(__AbstractPlainSocketImpl.java:__200) >>> at >>> java.net >>> .__AbstractPlainSocketImpl.__connect(__AbstractPlainSocketImpl.java:__182) >>> at >>> java.net.SocksSocketImpl.__connect(SocksSocketImpl.java:__391) >>> at java.net.Socket.connect(__Socket.java:579) >>> at java.net.Socket.connect(__Socket.java:528) >>> at java.net.Socket.(Socket.__java:425) >>> at java.net.Socket.(Socket.__java:241) >>> at HTTPClient.sslConnect(__HTTPClient.java:326) >>> at ConfigureCA.LoginPanel(__ConfigureCA.java:244) >>> at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) >>> at ConfigureCA.main(ConfigureCA.__java:1672) >>> java.lang.NullPointerException >>> at ConfigureCA.LoginPanel(__ConfigureCA.java:245) >>> at ConfigureCA.__ConfigureCAInstance(__ConfigureCA.java:1157) >>> at ConfigureCA.main(ConfigureCA.__java:1672) >>> >>> Now I seem to be stuck. I tried uninstalling the >>> freeipa-server package >>> with # yum remove freeipa-server and then reinstalled it the >>> same way, >>> but ipa-server-install won't run no matter what I attempt. >>> >>> Any thoughts? I'm pretty new to IPA. >>> >>> >>> There is a good chance this is due to a version mismatch between >>> the IPA packages and the dogtag packages. You didn't mention >>> which OS you're using nor the versions of the relevant packages, >>> that would have been helpful. In any event I would make sure all >>> your packages are up to date. >>> >>> >>> -- >>> John Dennis > >>> >>> >>> Looking to carve out IT costs? >>> www.redhat.com/carveoutcosts/ >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> >>> -- >>> Bret Wortman >>> The Damascus Group >>> Fairfax, VA >>> http://bretwortman.com/ >>> http://twitter.com/BretWortman >>> >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From giomac at gmail.com Thu Oct 18 10:49:30 2012 From: giomac at gmail.com (George Machitidze) Date: Thu, 18 Oct 2012 14:49:30 +0400 Subject: [Freeipa-users] Proven procedure for resetting admin password from CLI Message-ID: Hello I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find working procedure for that - all what I've found failed. Do we have any verified method/docs? Best regards, George Machitidze -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Thu Oct 18 11:23:33 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 18 Oct 2012 07:23:33 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <507F0457.50507@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> Message-ID: Tomcat is definitely not running and there's no log in /var/log/pki-ca. SELinux is disabled and not running. The same RPMs are installed on both my functioning and nonfunctioning system, at least as far as "# rpm -qa | grep tomcat | sort" revealed. I also followed Martin's suggestion to clean out the CA configuration, but that command seems to indicate that there wasn't any existing configuration: [root at fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... PKI instance Deletion Utility cleaning up instance ... No security domain defined. If this is an unconfigured instance, then that is OK. Otherwise, manually delete the entry from the security domain master. Removing selinux contexts [root at fs1 ~]# On Wed, Oct 17, 2012 at 3:17 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> Now it appears that whatever is supposed to be running on port 9445 >> (looks like mindarray-ca) isn't running, and I'm not sure how it gets >> started, exactly. I ran lsof -i:9445 on this server and on a FreeIPA >> test box I first set up, and it's running on the test box but not the >> new one. Where should I look next? >> > > See if there are any SELinux denials: ausearch -m AVC > > It looks like tomcat failed to start. The logs are in /var/log/pki-ca. > > rob > > >> On Wed, Oct 17, 2012 at 2:07 PM, Bret Wortman >> >> >> wrote: >> >> Spot on. It was a fresh install of F17 and I neglected to # yum >> update first. I've done so, rebooted, and am trying again with >> better results. >> >> >> On Wed, Oct 17, 2012 at 1:45 PM, John Dennis > > wrote: >> >> On 10/17/2012 12:40 PM, Bret Wortman wrote: >> >> I recently tried installing freeipa on a new server, but >> ipa-server-install had problems around this point: >> >> Configuring certificate server: Estimated time 3 minutes 30 >> seconds >> [1/18]: creating certificate server user >> [2/18]: creating pki-ca instance >> [3/18]: configuring certificate server instance >> ipa : CRITICAL failed to configure ca instance Command >> '/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname >> fs1.wedgeofli.me >> -cs_port 9445 >> >> -client_certdb_dir /tmp/tmp-UvBMbL -client_certdb_pwd XXXXXXXX >> -preop_pin HHxKHUz5RRfzQ3OkFMlR -domain_name IPA -admin_user >> admin >> -admin_email root at localhost -admin_XXXXXXXX XXXXXXXX >> -agent_name >> ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa >> -agent_cert_subject CN=ipa-ca-agent,O=WEDGEOFLI.ME >> >> >> -ldap_host fs1.wedgeofli.me >> -ldap_port 7389 >> >> -bind_dn cn=Directory Manager -bind_XXXXXXXX XXXXXXXX >> -base_dn o=ipaca >> -db_name ipaca -key_size 2048 -key_type rsa -key_algorithm >> SHA256withRSA >> -save_p12 true -backup_pwd XXXXXXXX -subsystem_name pki-cad >> -token_name >> internal -ca_subsystem_cert_subject___**name CN=CA >> Subsystem,O=WEDGEOFLI.ME >> >> -ca_ocsp_cert_subject_name CN=OCSP >> Subsystem,O=WEDGEOFLI.ME >> >> -ca_server_cert_subject_name CN=fs1.wedgeofli.me >> >> ,O=WE**__DGEOFLI.ME >> >> -ca_audit_signing_cert___**subject_name CN=CA >> Audit,O=WEDGEOFLI.ME >> >> -ca_sign_cert_subject_name >> CN=Certificate >> Authority,O=WEDGEOFLI.ME >> -external false -clone >> >> false' returned non-zero exit status 255 >> Unexpected error - see ipaserver-install.log for details: >> Configuration of CA failed >> [root at fs1 ~]# >> >> The logfile revealed the following stack trace: >> >> ##############################**__############### >> >> Attempting to connect to: fs1.wedgeofli.me:9445 >> >> >> >> Exception in LoginPanel(): java.lang.NullPointerException >> ERROR: ConfigureCA: LoginPanel() failure >> ERROR: unable to create CA >> >> ##############################** >> __############################**##__########### >> >> >> 2012-10-17T16:24:53Z DEBUG stderr=Exception: Unable to Send >> Request:java.net .__**ConnectException: >> >> Connection refused >> java.net.ConnectException: Connection refused >> at java.net.PlainSocketImpl.__**socketConnect(Native Method) >> at >> java.net >> .__**AbstractPlainSocketImpl.__** >> doConnect(__**AbstractPlainSocketImpl.java:_**_339) >> at >> java.net >> .__**AbstractPlainSocketImpl.__** >> connectToAddress(__**AbstractPlainSocketImpl.java:_**_200) >> at >> java.net >> .__**AbstractPlainSocketImpl.__**connect(__* >> *AbstractPlainSocketImpl.java:_**_182) >> at >> java.net.SocksSocketImpl.__**connect(SocksSocketImpl.java:_** >> _391) >> at java.net.Socket.connect(__**Socket.java:579) >> at java.net.Socket.connect(__**Socket.java:528) >> at java.net.Socket.(Socket.**__java:425) >> at java.net.Socket.(Socket.**__java:241) >> at HTTPClient.sslConnect(__**HTTPClient.java:326) >> at ConfigureCA.LoginPanel(__**ConfigureCA.java:244) >> at ConfigureCA.__**ConfigureCAInstance(__** >> ConfigureCA.java:1157) >> at ConfigureCA.main(ConfigureCA._**_java:1672) >> java.lang.NullPointerException >> at ConfigureCA.LoginPanel(__**ConfigureCA.java:245) >> at ConfigureCA.__**ConfigureCAInstance(__** >> ConfigureCA.java:1157) >> at ConfigureCA.main(ConfigureCA._**_java:1672) >> >> >> Now I seem to be stuck. I tried uninstalling the >> freeipa-server package >> with # yum remove freeipa-server and then reinstalled it the >> same way, >> but ipa-server-install won't run no matter what I attempt. >> >> Any thoughts? I'm pretty new to IPA. >> >> >> There is a good chance this is due to a version mismatch between >> the IPA packages and the dogtag packages. You didn't mention >> which OS you're using nor the versions of the relevant packages, >> that would have been helpful. In any event I would make sure all >> your packages are up to date. >> >> >> -- >> John Dennis > >> >> >> >> Looking to carve out IT costs? >> www.redhat.com/carveoutcosts/ > carveoutcosts/ > >> >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Oct 18 11:28:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 18 Oct 2012 13:28:29 +0200 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> Message-ID: <507FE7DD.70900@redhat.com> On 10/18/2012 01:23 PM, Bret Wortman wrote: > Tomcat is definitely not running and there's no log in /var/log/pki-ca. SELinux > is disabled and not running. The same RPMs are installed on both my functioning > and nonfunctioning system, at least as far as "# rpm -qa | grep tomcat | sort" > revealed. > > I also followed Martin's suggestion to clean out the CA configuration, but that > command seems to indicate that there wasn't any existing configuration: > > [root at fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib > -pki_instance_name=pki-ca --force > PKI instance Deletion Utility ... > > PKI instance Deletion Utility cleaning up instance ... > > No security domain defined. > If this is an unconfigured instance, then that is OK. > Otherwise, manually delete the entry from the security domain master. > > Removing selinux contexts Actually, I think that the pkiremove utility removed the leftover CA. If the CA was not there, the output should look like that: # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca --force PKI instance Deletion Utility ... [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not a legal directory. ... Can you try running the server install again? So that we can see if the CA cleanup helped? Martin From najum.c at gmail.com Thu Oct 18 11:33:14 2012 From: najum.c at gmail.com (Najmuddin) Date: Thu, 18 Oct 2012 17:03:14 +0530 Subject: [Freeipa-users] Proven procedure for resetting admin password from CLI In-Reply-To: References: Message-ID: You can reset it using ldappasswd. Eg: # ldappasswd -D "cn=Directory Manager" -W -s -H ldaps://ipa.server uid=admin,cn=users,cn=accounts, Note: You might need to prefix "LDAPTLS_CACERT=/etc/ipa/ca.crt" to the above command if the IPA CA cert is not mentioned in /etc/openldap/ldap.conf On Thu, Oct 18, 2012 at 4:19 PM, George Machitidze wrote: > Hello > > I want to reset admin password for FreeIPA 2.x (F17), but I couldn't find > working procedure for that - all what I've found failed. > Do we have any verified method/docs? > > Best regards, > George Machitidze > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -- Cheers Najmuddin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Thu Oct 18 11:35:36 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Thu, 18 Oct 2012 07:35:36 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <507FE7DD.70900@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> <507FE7DD.70900@redhat.com> Message-ID: Sorry, that wasn't clear at all, was it? The latest attempt was after I ran the cleanup. No joy; it's still failing at the same point and tomcat is definitely not running. On Thu, Oct 18, 2012 at 7:28 AM, Martin Kosek wrote: > On 10/18/2012 01:23 PM, Bret Wortman wrote: > > Tomcat is definitely not running and there's no log in /var/log/pki-ca. > SELinux > > is disabled and not running. The same RPMs are installed on both my > functioning > > and nonfunctioning system, at least as far as "# rpm -qa | grep tomcat | > sort" > > revealed. > > > > I also followed Martin's suggestion to clean out the CA configuration, > but that > > command seems to indicate that there wasn't any existing configuration: > > > > [root at fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib > > -pki_instance_name=pki-ca --force > > PKI instance Deletion Utility ... > > > > PKI instance Deletion Utility cleaning up instance ... > > > > No security domain defined. > > If this is an unconfigured instance, then that is OK. > > Otherwise, manually delete the entry from the security domain master. > > > > Removing selinux contexts > > Actually, I think that the pkiremove utility removed the leftover CA. If > the CA > was not there, the output should look like that: > > # /usr/bin/pkiremove -pki_instance_root=/var/lib -pki_instance_name=pki-ca > --force > PKI instance Deletion Utility ... > > [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not a > legal > directory. > ... > > Can you try running the server install again? So that we can see if the CA > cleanup helped? > > Martin > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Oct 18 11:43:44 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 18 Oct 2012 07:43:44 -0400 Subject: [Freeipa-users] Proven procedure for resetting admin password from CLI In-Reply-To: References: Message-ID: <507FEB70.90203@redhat.com> On 10/18/2012 06:49 AM, George Machitidze wrote: > Hello > > I want to reset admin password for FreeIPA 2.x (F17), but I couldn't > find working procedure for that - all what I've found failed. Can you please share what you tried and how it failed? > Do we have any verified method/docs? > > Best regards, > George Machitidze > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From jason.macklin at roche.com Thu Oct 18 11:48:58 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Thu, 18 Oct 2012 07:48:58 -0400 Subject: [Freeipa-users] Sudo works for full access, but not on a per command or host level. In-Reply-To: <507F0A8C.2020006@redhat.com> References: <507C761C.6040602@redhat.com> <507C86F3.8020603@redhat.com> <507D7000.8010300@redhat.com> <507D7B9A.9070909@redhat.com>, <9E312B5F-3598-4C53-A897-EEB78404F906@citrix.com> <507ED4FA.6000302@redhat.com> <507EE3B4.9050803@redhat.com> <507EFF87.8090009@redhat.com> <507F0A8C.2020006@redhat.com> Message-ID: Update with success! (but embarrassment) I apologize for putting everyone through the ringer on this one. Here is what I found. I mentioned at one point that my domainname/nisdomainname/dnsdomainname did not all return my correct domain, but that I had fixed this. As it turned out, I had a typo in my rc.local file. Fixing them so they return the correct value is not enough to fix sudo. I ran ipa-client --uninstall -->> yum remove ipa-client -->> yum install ipa-client -->> ipa-client-install and re-enrolled my client without making any other changes. Apparently, something does not translate properly during the enroll process if your domain is not set properly in the rc.local file. Everything is now working just as I would expect it to! Again, thank you everyone for your assistance! Cheers, Jason -----Original Message----- From: Rob Crittenden [mailto:rcritten at redhat.com] Sent: Wednesday, October 17, 2012 3:44 PM To: Macklin, Jason {DASB~Branford} Cc: dpal at redhat.com; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Sudo works for full access, but not on a per command or host level. Can you confirm that you have sudoer_debug set to 2? If I gather correctly, this is on RHEL 6.3? What version of sudo? I'm seeing different output. Mine includes the number of candidate results for sudoUser are found. If you watch /var/log/dirsrv/slapd-REALM/access on your IPA server you'll be able to see the LDAP searches the sudo client is making. The log is buffered so you won't see them immediately. Can you send us the queries that are being made? thanks rob From rcritten at redhat.com Thu Oct 18 12:54:18 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 08:54:18 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> <507FE7DD.70900@redhat.com> Message-ID: <507FFBFA.2060901@redhat.com> Bret Wortman wrote: > Sorry, that wasn't clear at all, was it? The latest attempt was after I > ran the cleanup. No joy; it's still failing at the same point and tomcat > is definitely not running. In order to diagnose why dogtag is failing to install we need to see the logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. You can send them directly to me or Martin if you'd prefer. rob > > On Thu, Oct 18, 2012 at 7:28 AM, Martin Kosek > wrote: > > On 10/18/2012 01:23 PM, Bret Wortman wrote: > > Tomcat is definitely not running and there's no log in > /var/log/pki-ca. SELinux > > is disabled and not running. The same RPMs are installed on both > my functioning > > and nonfunctioning system, at least as far as "# rpm -qa | grep > tomcat | sort" > > revealed. > > > > I also followed Martin's suggestion to clean out the CA > configuration, but that > > command seems to indicate that there wasn't any existing > configuration: > > > > [root at fs1 ~]# /usr/bin/pkiremove -pki_instance_root=/var/lib > > -pki_instance_name=pki-ca --force > > PKI instance Deletion Utility ... > > > > PKI instance Deletion Utility cleaning up instance ... > > > > No security domain defined. > > If this is an unconfigured instance, then that is OK. > > Otherwise, manually delete the entry from the security domain master. > > > > Removing selinux contexts > > Actually, I think that the pkiremove utility removed the leftover > CA. If the CA > was not there, the output should look like that: > > # /usr/bin/pkiremove -pki_instance_root=/var/lib > -pki_instance_name=pki-ca --force > PKI instance Deletion Utility ... > > [error] /usr/bin/pkiremove: Target directory /var/lib/pki-ca is not > a legal > directory. > ... > > Can you try running the server install again? So that we can see if > the CA > cleanup helped? > > Martin > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > From simo at redhat.com Thu Oct 18 13:30:03 2012 From: simo at redhat.com (Simo Sorce) Date: Thu, 18 Oct 2012 09:30:03 -0400 Subject: [Freeipa-users] Proven procedure for resetting admin password from CLI In-Reply-To: References: Message-ID: <1350567003.30610.94.camel@willson.li.ssimo.org> On Thu, 2012-10-18 at 14:49 +0400, George Machitidze wrote: > Hello > > > I want to reset admin password for FreeIPA 2.x (F17), but I couldn't > find working procedure for that - all what I've found failed. > Do we have any verified method/docs? ipa passwd or kpasswd should work just fine. you should also be able to use ldappasswd if you prefer that. Can you tell exactly what failed an how ? Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Oct 18 14:46:50 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 18 Oct 2012 10:46:50 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <507FFBFA.2060901@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> <507FE7DD.70900@redhat.com> <507FFBFA.2060901@redhat.com> Message-ID: <5080165A.7010000@redhat.com> Rob Crittenden wrote: > Bret Wortman wrote: >> Sorry, that wasn't clear at all, was it? The latest attempt was after I >> ran the cleanup. No joy; it's still failing at the same point and tomcat >> is definitely not running. > > In order to diagnose why dogtag is failing to install we need to see the > logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. > You can send them directly to me or Martin if you'd prefer. > To close the loop on this, I had Bret yum reinstall the pki-selinux package. For some reason sometimes it fails to load the required SELinux contents on install. Doing that has resolved the installation issue. rob From bjvetter at gmail.com Fri Oct 19 04:35:20 2012 From: bjvetter at gmail.com (Brian Vetter) Date: Thu, 18 Oct 2012 23:35:20 -0500 Subject: [Freeipa-users] web admin tool will not login with kerberos ticket In-Reply-To: <507EA975.4000301@redhat.com> References: <507EA975.4000301@redhat.com> Message-ID: <21FFCC5A-65B8-4B25-BA29-2740CE791B5C@gmail.com> I followed Rob's advice and enabled the http debug logging. I'm no expert here but I didn't really see anything that indicates an error. I do see a series of connections to the server and GSS/kerberos log messages (like "client delegates us their credentials" and "GSS-API token of length 22 bytes will be sent back..."). The log just stops and apache returns an authentication error. While reading the logs, I did notice a reference to s4u2proxy. When I looked around for that, I ran across a blog article from idra at samba.org where he described how they modified mod_auth_kerb for FreeIPA. On suspecting something went wrong with the installation (like some update that replaced mod_auth_kerb or something related), I did a "yum reinstall freeipa-server". After it completed, everything started working as it had in the past. So while I don't know for sure, I believe some other package that was updated (perhaps apache) overwrote something in FreeIPA (perhaps mod_auth_kerb). In any case, I'm whole again. Brian On Oct 17, 2012, at 7:49 AM, Rob Crittenden wrote: > Brian Vetter wrote: >> I had a happy, working 2.2 FreeIPA installation humming along last >> week. I had to do some maintenance so I shut everything down. When I >> brought everything up, I can no longer log into the web admin tool. I >> get a "Kerberos ticket is no longer valid" error. >> >> Using the troubleshooting pages on the wiki as a guide, I can kinit >> successfully and see the tickets using klist. I can use the ldapsearch >> tool using GSSAPI to authenticate as well and can return results from >> the ldap server. 'ldapsearch -Y GSSAPI -b "dc=dcc,dc=mobi" uid=admin' >> returns a valid ldap recors for my admin user. I ran this command kinit >> from multiple kerberos principals/users and each worked. >> >> I verified my config settings again with firefox and they are still set >> correctly (auth.delegation-uris, auth.trusted-users both set to my >> domain .dcc.mobi). The cert was accepted (no warnings about the cert not >> being trusted because I had already set it to trusted). I turned on the >> NSPR logging as described in the documents, and didn't see an error, >> although I can't tell if this is correct: >> >> 492291904[7f4d1d31f6a0]: using REQ_DELEGATE >> 492291904[7f4d1d31f6a0]: service = geonosis.dcc.mobi >> 492291904[7f4d1d31f6a0]: using negotiate-gss >> 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::nsAuthGSSAPI() >> 492291904[7f4d1d31f6a0]: Attempting to load gss functions >> 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::Init() >> 492291904[7f4d1d31f6a0]: nsHttpNegotiateAuth::GenerateCredentials() >> [challenge=Negotiate] >> 492291904[7f4d1d31f6a0]: entering nsAuthGSSAPI::GetNextToken() >> 492291904[7f4d1d31f6a0]: leaving nsAuthGSSAPI::GetNextToken [rv=0] >> 492291904[7f4d1d31f6a0]: Sending a token of length 1394 >> >> >> There is nothing in /var/log/httpd/error_log. /var/log/httpd/access_log >> does have a few entries: >> >> 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ca/ocsp HTTP/1.1" >> 200 2298 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:16.0) >> Gecko/20100101 Firefox/16.0" >> 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json >> HTTP/1.1" 401 - >> 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "GET >> /ipa/session/login_kerberos HTTP/1.1" 401 1861 >> 10.1.1.10 - admin at DCC.MOBI >> [16/Oct/2012:18:05:26 -0500] "GET /ipa/session/login_kerberos >> HTTP/1.1" 200 - >> 10.1.1.10 - - [16/Oct/2012:18:05:26 -0500] "POST /ipa/session/json >> HTTP/1.1" 401 - >> >> >> The 401's aren't surprising here since somehow, something is not >> properly authenticating. >> >> I also looked in /var/log/krb5kdc.log and see the following line when >> authenticating: >> >> Oct 16 18:12:17 geonosis.dcc.mobi krb5kdc[1193](info): TGS_REQ (1 >> etypes {18}) 10.1.1.10: ISSUE: authtime 1350424404, etypes {rep=18 >> tkt=18 ses=18}, admin at DCC.MOBI for >> krbtgt/DCC.MOBI at DCC.MOBI >> >> >> I don't believe this describes an error, but I'm not an expert reading >> that log type. >> >> From what I can tell, the problems seem to be between the apache server >> and the browser. Both worked fine together last week. Is there something >> I can turn on in Apache (perhaps in the ipa.conf or auth_kerb.conf >> files) that can help debug this? Or better yet, anyone else seen this >> and have an answer? Is there some key/ticket/etc associated with the >> http server that might be "wrong" now (somehow whacked during the reboot)? > > If you set LogLevel debug in /etc/httpd/conf.d/nss.conf and restart the httpd service you'll get a lot of debugging output from ipa and mod_auth_kerb, one of which may provide some pointers. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Oct 19 18:26:46 2012 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 19 Oct 2012 14:26:46 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <5080165A.7010000@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> <507FE7DD.70900@redhat.com> <507FFBFA.2060901@redhat.com> <5080165A.7010000@redhat.com> Message-ID: <50819B66.20600@redhat.com> On 10/18/2012 10:46 AM, Rob Crittenden wrote: > Rob Crittenden wrote: >> Bret Wortman wrote: >>> Sorry, that wasn't clear at all, was it? The latest attempt was after I >>> ran the cleanup. No joy; it's still failing at the same point and >>> tomcat >>> is definitely not running. >> >> In order to diagnose why dogtag is failing to install we need to see the >> logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. >> You can send them directly to me or Martin if you'd prefer. >> > > To close the loop on this, I had Bret yum reinstall the pki-selinux > package. For some reason sometimes it fails to load the required > SELinux contents on install. Is there any way to make it more reliable? > > Doing that has resolved the installation issue. > > rob > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sakodak at gmail.com Fri Oct 19 19:31:03 2012 From: sakodak at gmail.com (KodaK) Date: Fri, 19 Oct 2012 14:31:03 -0500 Subject: [Freeipa-users] Changing randomly generated password complexity? Message-ID: Hello all, Does anyone know if it's possible to change the complexity of the passwords that IPA generates? Here's a typical scenario: User: "can you reset my password?" Me: "Random password: 9opLSv6jhN_Q" User: "it doesn't work." Me: (internal sigh) "can you copy and paste it, you only need it once and then you can reset it to whatever you want." User: "it still doesn't work." Me: "your password is now 'bob'." User: "it works now!" -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From jason.macklin at roche.com Fri Oct 19 19:37:40 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Fri, 19 Oct 2012 15:37:40 -0400 Subject: [Freeipa-users] Changing randomly generated password complexity? In-Reply-To: References: Message-ID: Yes, Click the policy tab and choose global policies. Change the character classes setting to something less then what is already there. This number reflects how many requirements the user password has to meet. Cheers, Jason -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of KodaK Sent: Friday, October 19, 2012 3:31 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] Changing randomly generated password complexity? Hello all, Does anyone know if it's possible to change the complexity of the passwords that IPA generates? Here's a typical scenario: User: "can you reset my password?" Me: "Random password: 9opLSv6jhN_Q" User: "it doesn't work." Me: (internal sigh) "can you copy and paste it, you only need it once and then you can reset it to whatever you want." User: "it still doesn't work." Me: "your password is now 'bob'." User: "it works now!" -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Fri Oct 19 19:41:08 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 19 Oct 2012 15:41:08 -0400 Subject: [Freeipa-users] Changing randomly generated password complexity? In-Reply-To: References: Message-ID: <5081ACD4.4020006@redhat.com> KodaK wrote: > Hello all, > > Does anyone know if it's possible to change the complexity of the > passwords that IPA generates? > > Here's a typical scenario: > > User: "can you reset my password?" > > Me: "Random password: 9opLSv6jhN_Q" > > User: "it doesn't work." > > Me: (internal sigh) "can you copy and paste it, you only need it once > and then you can reset it to whatever you want." > > User: "it still doesn't work." > > Me: "your password is now 'bob'." > > User: "it works now!" > Not at the moment, it's hardcoded. I'd be curious why it was failing. Is it a matter of transcribing the new password to the user or something else? rob From jason.macklin at roche.com Fri Oct 19 19:59:43 2012 From: jason.macklin at roche.com (Macklin, Jason) Date: Fri, 19 Oct 2012 15:59:43 -0400 Subject: [Freeipa-users] Changing randomly generated password complexity? In-Reply-To: <5081ACD4.4020006@redhat.com> References: <5081ACD4.4020006@redhat.com> Message-ID: Whoops, Saw password complexity, but obviously I didn't read the entire title. Sorry about that. Good luck! -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Friday, October 19, 2012 3:41 PM To: KodaK Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Changing randomly generated password complexity? KodaK wrote: > Hello all, > > Does anyone know if it's possible to change the complexity of the > passwords that IPA generates? > > Here's a typical scenario: > > User: "can you reset my password?" > > Me: "Random password: 9opLSv6jhN_Q" > > User: "it doesn't work." > > Me: (internal sigh) "can you copy and paste it, you only need it once > and then you can reset it to whatever you want." > > User: "it still doesn't work." > > Me: "your password is now 'bob'." > > User: "it works now!" > Not at the moment, it's hardcoded. I'd be curious why it was failing. Is it a matter of transcribing the new password to the user or something else? rob _______________________________________________ Freeipa-users mailing list Freeipa-users at redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users From simo at redhat.com Fri Oct 19 20:35:31 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 19 Oct 2012 16:35:31 -0400 Subject: [Freeipa-users] Failed installation In-Reply-To: <50819B66.20600@redhat.com> References: <507EEEC8.4090607@redhat.com> <507F0457.50507@redhat.com> <507FE7DD.70900@redhat.com> <507FFBFA.2060901@redhat.com> <5080165A.7010000@redhat.com> <50819B66.20600@redhat.com> Message-ID: <1350678931.30610.144.camel@willson.li.ssimo.org> On Fri, 2012-10-19 at 14:26 -0400, Dmitri Pal wrote: > On 10/18/2012 10:46 AM, Rob Crittenden wrote: > > Rob Crittenden wrote: > >> Bret Wortman wrote: > >>> Sorry, that wasn't clear at all, was it? The latest attempt was after I > >>> ran the cleanup. No joy; it's still failing at the same point and > >>> tomcat > >>> is definitely not running. > >> > >> In order to diagnose why dogtag is failing to install we need to see the > >> logs from /var/log/pki-ca and the full /var/log/ipaserver-install.log. > >> You can send them directly to me or Martin if you'd prefer. > >> > > > > To close the loop on this, I had Bret yum reinstall the pki-selinux > > package. For some reason sometimes it fails to load the required > > SELinux contents on install. > > Is there any way to make it more reliable? The dogtag selinux policy is being merged into the system policy. This should remove the issue completely in future Fedora versions. Simo. -- Simo Sorce * Red Hat, Inc * New York From antti.peltonen at iki.fi Mon Oct 22 08:54:07 2012 From: antti.peltonen at iki.fi (Antti Peltonen) Date: Mon, 22 Oct 2012 11:54:07 +0300 Subject: [Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit "problem" In-Reply-To: References: Message-ID: Hi all, To answer my own question: Policykit fetches its admin identities from a policy file (atleast in Fedora 17) from file: /etc/polkit-1/localauthority.conf.d/50-localauthority.conf Contents of original file: ------------------------------------------->o----------------------------------- # Configuration file for the PolicyKit Local Authority. # # DO NOT EDIT THIS FILE, it will be overwritten on update. # # See the pklocalauthority(8) man page for more information # about configuring the Local Authority. # [Configuration] AdminIdentities=unix-group:wheel ------------------------------------------->o----------------------------------- This file has warning labels that the file should not be edited since it will be overwritten by package updates. So the recommend process is to copy that file to another name like 90-custom.conf and modify its contents as follows: ------------------------------------------->o----------------------------------- [Configuration] AdminIdentities=unix-group:wheel;unix-group:fullsudo ------------------------------------------->o----------------------------------- where unix group "fullsudo" is an POSIX group provisioned in FreeIPA domain and users of that group have full sudo rights through sudo rules. -Antti- p.s. Adding my freeipa user in local wheel group worked after logon after all too. I wonder if I did not test enough before complaining about it but I was _sure_ that I did logout and back in before testing but it would seem that I did not. On 16 October 2012 09:53, Antti Peltonen wrote: > Hi all, > > Just playing around with my setup that consists of two FreeIPA domain > controllers on CentOS6.3 so the version of FreeIPA in use there is 2.2.0 > > So now after setting up my test laptop with Fedora 17 I proceeded to do an > client installation and it seems freeipa-client version on F17 is also > 2.2.0 but such things as sudo and sssd are much more recent than on CentOS. > This caused few grey hairs until I got the sudo configuration to work by > manipulating sssd.conf. > > Now that my user provisioned in FreeIPA domain can logon to my laptop, use > sudo etc to install software I noticed a one little issue with policykit + > packagekit combination. When through X I try to install an RPM package or > do anything that requires admin rights it keeps asking for the root users > password and not my sudo enabled FreeIPA users. > > If I have understood correctly packagekit advertises its request for admin > rights through dbus to policykit which reads its policy files for matching > description about the request. In this case the file seems to > be: /usr/share/polkit-1/actions/org.freedesktop.packagekit.policy > > In this policy file there is a lot of stuff which at this point makes no > sense to me at all except that I guess that the > lines: auth_admin describe that policykit > should require user to enter an administrative level users password. Now on > basic F17 installation where after first boot you create your first normal > user account and give it an password there is an checkbox for > "Administrator" or something similar which seems to add this user to be > created in "wheel" and "adm" posix groups. When policykit requires an > administrative users password it asks for this local users password if it > is member of those groups (I guess) and if not it asks for the root users > password. > > However when I add my FreeIPA user to the adm and wheel groups (silly > since my sudo rules in FreeIPA give me already a full sudo rights) > policykit does not seem to make a sense out of this situation and keep > asking for the root users password. > > Now after all this bad english and a load of factual errors the actual > question is: What needs to be configured and how to make FreeIPA > provisioned user to be "local administrator" in policykits mind? If this is > at all possible in current stage of development... > > p.s. I use an PackageKit here as an example target for the PolicyKit but I > guess that anything to do with process rights elevation through PolicyKit > is affected - not just the PackageKit application. > > -- > Antti Peltonen | Homo sapiens | planet Earth > email antti.peltonen at iki.fi > irc BCOW @ IRCNet | Twitter @BrainCOW > > "Ars longa, vita previs." > > -- Antti Peltonen | Homo sapiens | planet Earth email antti.peltonen at iki.fi | cellular +358 44 328 5555 irc BCOW @ IRCNet | Twitter @BrainCOW "Ars longa, vita previs." -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at gmail.com Mon Oct 22 18:28:35 2012 From: fvzwieten at gmail.com (Fred van Zwieten) Date: Mon, 22 Oct 2012 20:28:35 +0200 Subject: [Freeipa-users] DNS forwarding problem Message-ID: Hello, I have a problem. My setup: - IPA server for domain example.com on ipa.example.com - DNS server sub.example.com on host.sub.example.com - client.example.com with IP-nr off ipa.example.com in resolv.conf - an A record for client.sub.example.com in DNS server host.sub.example.com Problem: I cannot resolve the address of client.sub.example.com from client.example.com. I have tried all kinds of configs: 1. Configured global forwarding in named.conf on ipa.example.com 2. Configured zone forwarding in named.conf on ipa.example.com for zone sub.example.com 3. Configured global forwarding in IPA server 4. Add a zone sub.example.conf in IPA and configured forwarding on that zone. Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the DNS server on host.sub.example.com directly, it resolves. Using RHEL6.3 on all hosts. I found an old bugzilla on recursion problems. in namd.conf recursion is allowed for "any". Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Mon Oct 22 18:30:54 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 22 Oct 2012 20:30:54 +0200 Subject: [Freeipa-users] DNS forwarding problem In-Reply-To: References: Message-ID: Hello, > > I have a problem. My setup: > > - IPA server for domain example.com on ipa.example.com > - DNS server sub.example.com on host.sub.example.com > - client.example.com with IP-nr off ipa.example.com in resolv.conf > - an A record for client.sub.example.com in DNS server > host.sub.example.com > > Problem: I cannot resolve the address of client.sub.example.com from > client.example.com. > > I have tried all kinds of configs: > 1. Configured global forwarding in named.conf on ipa.example.com > 2. Configured zone forwarding in named.conf on ipa.example.com for zone > sub.example.com > 3. Configured global forwarding in IPA server > 4. Add a zone sub.example.conf in IPA and configured forwarding on that > zone. > > Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the > DNS server on host.sub.example.com directly, it resolves. > > Using RHEL6.3 on all hosts. > > I found an old bugzilla on recursion problems. in namd.conf recursion is > allowed for "any". > > Fred > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fvzwieten at vxcompany.com Mon Oct 22 18:57:56 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Mon, 22 Oct 2012 20:57:56 +0200 Subject: [Freeipa-users] DNS forward to sub domain not working Message-ID: Hello, I have a problem. My setup: - IPA server for domain example.com on ipa.example.com - DNS server sub.example.com on host.sub.example.com - client.example.com with IP-nr off ipa.example.com in resolv.conf - an A record for client.sub.example.com in DNS server host.sub.example.com Problem: I cannot resolve the address of client.sub.example.com from client.example.com. I have tried all kinds of configs: 1. Configured global forwarding in named.conf on ipa.example.com 2. Configured zone forwarding in named.conf on ipa.example.com for zone sub.example.com 3. Configured global forwarding in IPA server 4. Add a zone sub.example.conf in IPA and configured forwarding on that zone. Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the DNS server on host.sub.example.com directly, it resolves. Using RHEL6.3 on all hosts. I found an old bugzilla on recursion problems. in namd.conf recursion is allowed for "any". I'm not sure if this is a IPA or a DNS issue.. Fred -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Oct 22 20:00:30 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 22 Oct 2012 16:00:30 -0400 Subject: [Freeipa-users] CentOS6.3 + Fedora17 + PackageKit / PolicyKit "problem" In-Reply-To: References: Message-ID: <5085A5DE.7030808@redhat.com> Antti Peltonen wrote: > Hi all, > > To answer my own question: > > Policykit fetches its admin identities from a policy file (atleast in > Fedora 17) from > file: /etc/polkit-1/localauthority.conf.d/50-localauthority.conf > > Contents of original file: > > ------------------------------------------->o----------------------------------- > # Configuration file for the PolicyKit Local Authority. > # > # DO NOT EDIT THIS FILE, it will be overwritten on update. > # > # See the pklocalauthority(8) man page for more information > # about configuring the Local Authority. > # > > [Configuration] > AdminIdentities=unix-group:wheel > ------------------------------------------->o----------------------------------- > > This file has warning labels that the file should not be edited since it > will be overwritten by package updates. So the recommend process is to > copy that file to another name like 90-custom.conf and modify its > contents as follows: > > ------------------------------------------->o----------------------------------- > [Configuration] > AdminIdentities=unix-group:wheel;unix-group:fullsudo > ------------------------------------------->o----------------------------------- > > where unix group "fullsudo" is an POSIX group provisioned in FreeIPA > domain and users of that group have full sudo rights through sudo rules. > > -Antti- > > p.s. Adding my freeipa user in local wheel group worked after logon > after all too. I wonder if I did not test enough before complaining > about it but I was _sure_ that I did logout and back in before testing > but it would seem that I did not. Thanks for the follow-up. I opened a doc ticket so we can add this to our documentation: https://fedorahosted.org/freeipa/ticket/3203 rob From sigbjorn at nixtra.com Mon Oct 22 21:14:26 2012 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Mon, 22 Oct 2012 23:14:26 +0200 Subject: [Freeipa-users] Easy deployment In-Reply-To: <50645B90.6040304@redhat.com> References: <50621178.7080208@nixtra.com> <50645B90.6040304@redhat.com> Message-ID: <5085B732.60909@nixtra.com> On 09/27/2012 03:58 PM, Dmitri Pal wrote: > On 09/25/2012 04:18 PM, Sigbjorn Lie wrote: >> On 09/25/2012 12:17 AM, James James wrote: >>> Hi guys, >>> >>> we are planning to install 150 freeipa clients and I was wondering >>> if there is a way to easily install (from kickstart) nfsv4 client. >>> >>> I can add host with >>> >>> # ipa host-add --password=secret >>> >>> But to get the keytab (host and service), I have to log into the >>> machine, launch kinit and get the keytab. >>> >>> This will be very painful for 150 clients .... >>> >>> Any hints is welcome ... >>> >>> >>> _______________________________________________ >>> Freeipa-users mailing list >>> Freeipa-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/freeipa-users >> Hi, >> >> I am working on integrating what you are asking for into >> OneClickKick. OneClickKick which is a web based GUI for managing DHCP >> server and PXE booting. The current version can read the host objects >> from IPA's LDAP, and you can use these to generate PXE boot files for >> kickstarting RHEL/Fedora, preseeding Debian/Ubuntu installations, do >> BIOS upgrades, run LIVE environments, etc. >> >> What I have done in the past is to add a line like this to the post >> section of the kickstart: >> /usr/sbin/ipa-client-install --domain="ix.test.com" >> --principal="ipajoinuser" --password="somepassword" -U -f >> >> This is not ideal even though the kickstart is saved in a database >> and only made available dynamically trough a php script to the host >> that's enabled for kickstarting. It is not saved in a text file on >> the disk. The next version will include tighter integration with IPA >> where a One Time Password is set for the host being kickstarted at >> the time it's enabled for kickstarting, and this password is seeded >> dynamically when the host is served it's kickstart file. >> >> The next version will also have the PXE Enrollment boot image updated >> to supporting adding new hosts directly into IPA. The PXE Enrollment >> is support for adding a new host simply to PXE booting it, logging >> on, and giving it a hostname and assigning it with a kickstart >> profile to load the machine directly from the console of the new >> machine. >> >> Adding of machines directly to IPA from the web UI will also be >> available in the next version. This allows you to do everything from >> adding the host, to selecting the kickstart profile group, and >> enabling for PXE installation/kickstart in 1 step. >> >> It can also search trough the /var/log/messages file to find new >> hosts that's unknown to it's naming sources and directly add these. >> >> You can also select a group of machine to install, so if you have >> your 150 machines in one group you can select the entire group for >> installation. >> >> >> See the project website or contact me for more information: >> http://sourceforge.net/projects/oneclickkick/ >> >> > > Have you looked at Foreman? Foreman did not exist back when I started working on OneClickKick. I've not looked much into Foreman later. Rgds, Siggi -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Oct 23 07:36:39 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Oct 2012 09:36:39 +0200 Subject: [Freeipa-users] DNS forwarding problem In-Reply-To: References: Message-ID: <50864907.9040403@redhat.com> On 10/22/2012 08:28 PM, Fred van Zwieten wrote: > Hello, > > I have a problem. My setup: > > - IPA server for domain example.com on ipa.example.com > > - DNS server sub.example.com on host.sub.example.com > You mean your own DNS server that is configured via BIND files? I.e. not a IPA DNS server configured with ipa-dns-install? > - client.example.com with IP-nr off ipa.example.com > in resolv.conf > - an A record for client.sub.example.com in DNS > server host.sub.example.com > > Problem: I cannot resolve the address of client.sub.example.com > from client.example.com > . > > I have tried all kinds of configs: > 1. Configured global forwarding in named.conf on ipa.example.com > > 2. Configured zone forwarding in named.conf on ipa.example.com > for zone sub.example.com Hmm, I am not sure if this works well when you combine file+LDAP configuration for the same zone. Petr Spacek may want to chime in. > 3. Configured global forwarding in IPA server > 4. Add a zone sub.example.conf in IPA and configured forwarding on that zone. I think this should work. I assume that "sub.example.conf" is just a typo. Can you please test with the following tcpdump command to see where are the DNS queries are actually sent? # tcpdump -ni eth0 udp port 53 Another option to delegate a zone to another machine would be to create an NS record sub.example.com on ipa.example.com pointing to "host.sub.example.com.". (host.sub.example.com. has to be resolvable from ipa.example.com so that it knows where to forward the query). Martin > > Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the DNS > server on host.sub.example.com directly, it resolves. > > Using RHEL6.3 on all hosts. > > I found an old bugzilla on recursion problems. in namd.conf recursion is > allowed for "any". > > Fred From sbose at redhat.com Tue Oct 23 07:51:25 2012 From: sbose at redhat.com (Sumit Bose) Date: Tue, 23 Oct 2012 09:51:25 +0200 Subject: [Freeipa-users] DNS forward to sub domain not working In-Reply-To: References: Message-ID: <20121023075125.GL23959@localhost.localdomain> On Mon, Oct 22, 2012 at 08:57:56PM +0200, Fred van Zwieten wrote: > Hello, > > I have a problem. My setup: > > - IPA server for domain example.com on ipa.example.com > - DNS server sub.example.com on host.sub.example.com > - client.example.com with IP-nr off ipa.example.com in resolv.conf > - an A record for client.sub.example.com in DNS server host.sub.example.com > > Problem: I cannot resolve the address of client.sub.example.com from > client.example.com. > > I have tried all kinds of configs: > 1. Configured global forwarding in named.conf on ipa.example.com > 2. Configured zone forwarding in named.conf on ipa.example.com for zone > sub.example.com > 3. Configured global forwarding in IPA server > 4. Add a zone sub.example.conf in IPA and configured forwarding on that > zone. > > Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the DNS > server on host.sub.example.com directly, it resolves. > > Using RHEL6.3 on all hosts. > > I found an old bugzilla on recursion problems. in namd.conf recursion is > allowed for "any". I think it is not a recursion issue, but related to delegation. Since the IPA DNS server on ipa.example.com thinks he is responsible/authoritative for the whole example.com he would also try to handle request for sub.example.com. You have to tell the DNS serve explicitly that there is another DNS server for sub.example.com by calling: ipa dnsrecord-add example.com subdns --a-ip-address=1.2.3.4 ipa dnsrecord-add example.com sub --ns-hostname=subdns Please note that the DNS server for sub.example.com is now called 'subdns.example.com' since a name from the example.com domain is needed because otherwise the name cannot be resolved. HTH bye, Sumit > > I'm not sure if this is a IPA or a DNS issue.. > > Fred > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From pspacek at redhat.com Tue Oct 23 08:00:06 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Oct 2012 10:00:06 +0200 Subject: [Freeipa-users] DNS forward to sub domain not working In-Reply-To: <20121023075125.GL23959@localhost.localdomain> References: <20121023075125.GL23959@localhost.localdomain> Message-ID: <50864E86.9000602@redhat.com> On 10/23/2012 09:51 AM, Sumit Bose wrote: > On Mon, Oct 22, 2012 at 08:57:56PM +0200, Fred van Zwieten wrote: >> Hello, >> >> I have a problem. My setup: >> >> - IPA server for domain example.com on ipa.example.com >> - DNS server sub.example.com on host.sub.example.com >> - client.example.com with IP-nr off ipa.example.com in resolv.conf >> - an A record for client.sub.example.com in DNS server host.sub.example.com >> >> Problem: I cannot resolve the address of client.sub.example.com from >> client.example.com. >> >> I have tried all kinds of configs: >> 1. Configured global forwarding in named.conf on ipa.example.com >> 2. Configured zone forwarding in named.conf on ipa.example.com for zone >> sub.example.com >> 3. Configured global forwarding in IPA server >> 4. Add a zone sub.example.conf in IPA and configured forwarding on that >> zone. >> >> Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the DNS >> server on host.sub.example.com directly, it resolves. >> >> Using RHEL6.3 on all hosts. >> >> I found an old bugzilla on recursion problems. in namd.conf recursion is >> allowed for "any". > > I think it is not a recursion issue, but related to delegation. Since > the IPA DNS server on ipa.example.com thinks he is > responsible/authoritative for the whole example.com he would also try to > handle request for sub.example.com. > > You have to tell the DNS serve explicitly that there is another DNS > server for sub.example.com by calling: > > ipa dnsrecord-add example.com subdns --a-ip-address=1.2.3.4 > ipa dnsrecord-add example.com sub --ns-hostname=subdns > > Please note that the DNS server for sub.example.com is now called > 'subdns.example.com' since a name from the example.com domain is needed > because otherwise the name cannot be resolved. > > HTH > > bye, > Sumit > >> >> I'm not sure if this is a IPA or a DNS issue.. >> >> Fred Hello, please don't use forwarders, just create a NS+A record pair for "sub.example.com" domain in IPA DNS as Sumit wrote above. Current version seems to have some problems with forwarders, I will investigate it. Configuration with forwarders are often confusing, please don't use them if it is not necessary. -- Petr^2 Spacek From fvzwieten at vxcompany.com Tue Oct 23 08:29:03 2012 From: fvzwieten at vxcompany.com (Fred van Zwieten) Date: Tue, 23 Oct 2012 10:29:03 +0200 Subject: [Freeipa-users] DNS forward to sub domain not working In-Reply-To: <50864E86.9000602@redhat.com> References: <20121023075125.GL23959@localhost.localdomain> <50864E86.9000602@redhat.com> Message-ID: Hi all, Thank you for you're input. I found a more or less similar solution here (I tried Google first, but the art there is to formulate the correct search phrase..). I seem to have it working by doing this: 1. Add A record for subns.example.com 2. Add NS record for sub.example.com to subns.example.com Although Petr says to stay away from forwarder, it does not work without them. I had to enter zone forwarding addresses on example.com. After updates I only got it working after restarting named on the IPA server. Thank you for the answers Fred On Tue, Oct 23, 2012 at 10:00 AM, Petr Spacek wrote: > On 10/23/2012 09:51 AM, Sumit Bose wrote: > > On Mon, Oct 22, 2012 at 08:57:56PM +0200, Fred van Zwieten wrote: > >> Hello, > >> > >> I have a problem. My setup: > >> > >> - IPA server for domain example.com on ipa.example.com > >> - DNS server sub.example.com on host.sub.example.com > >> - client.example.com with IP-nr off ipa.example.com in resolv.conf > >> - an A record for client.sub.example.com in DNS server > host.sub.example.com > >> > >> Problem: I cannot resolve the address of client.sub.example.com from > >> client.example.com. > >> > >> I have tried all kinds of configs: > >> 1. Configured global forwarding in named.conf on ipa.example.com > >> 2. Configured zone forwarding in named.conf on ipa.example.com for zone > >> sub.example.com > >> 3. Configured global forwarding in IPA server > >> 4. Add a zone sub.example.conf in IPA and configured forwarding on that > >> zone. > >> > >> Nothing works. I keep getting NXDOMAIN when doing a dig. If I query the > DNS > >> server on host.sub.example.com directly, it resolves. > >> > >> Using RHEL6.3 on all hosts. > >> > >> I found an old bugzilla on recursion problems. in namd.conf recursion is > >> allowed for "any". > > > > I think it is not a recursion issue, but related to delegation. Since > > the IPA DNS server on ipa.example.com thinks he is > > responsible/authoritative for the whole example.com he would also try to > > handle request for sub.example.com. > > > > You have to tell the DNS serve explicitly that there is another DNS > > server for sub.example.com by calling: > > > > ipa dnsrecord-add example.com subdns --a-ip-address=1.2.3.4 > > ipa dnsrecord-add example.com sub --ns-hostname=subdns > > > > Please note that the DNS server for sub.example.com is now called > > 'subdns.example.com' since a name from the example.com domain is needed > > because otherwise the name cannot be resolved. > > > > HTH > > > > bye, > > Sumit > > > >> > >> I'm not sure if this is a IPA or a DNS issue.. > >> > >> Fred > > Hello, > > please don't use forwarders, just create a NS+A record pair for > "sub.example.com" domain in IPA DNS as Sumit wrote above. > > Current version seems to have some problems with forwarders, I will > investigate it. > > Configuration with forwarders are often confusing, please don't use them > if it > is not necessary. > > -- > Petr^2 Spacek > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Oct 23 08:53:43 2012 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 23 Oct 2012 10:53:43 +0200 Subject: [Freeipa-users] DNS forward to sub domain not working In-Reply-To: References: <20121023075125.GL23959@localhost.localdomain> <50864E86.9000602@redhat.com> Message-ID: <50865B17.4060303@redhat.com> On 10/23/2012 10:29 AM, Fred van Zwieten wrote: > Hi all, > > Thank you for you're input. I found a more or less similar solution here > (I > tried Google first, but the art there is to formulate the correct search > phrase..). > > I seem to have it working by doing this: > > 1. Add A record for subns.example.com > 2. Add NS record for sub.example.com to > subns.example.com > > Although Petr says to stay away from forwarder, it does not work without them. > I had to enter zone forwarding addresses on example.com . > > After updates I only got it working after restarting named on the IPA server. > > Thank you for the answers > > Fred Hello, please provide detailed configuration for IPA and "sub" DNS server and I will investigate it. For IPA, best way is to export whole DNS subtree to ldif: $ kinit admin $ ldapsearch -Y GSSAPI -b 'cn=dns,dc=example,dc=com' > /tmp/ipa.ldif /var/named/* and /etc/named.conf files from both servers (IPA and also plain BIND) would be useful. You can post these files to me privately if you want. Thank you! Petr^2 Spacek > > On Tue, Oct 23, 2012 at 10:00 AM, Petr Spacek > wrote: > > On 10/23/2012 09:51 AM, Sumit Bose wrote: > > On Mon, Oct 22, 2012 at 08:57:56PM +0200, Fred van Zwieten wrote: > >> Hello, > >> > >> I have a problem. My setup: > >> > >> - IPA server for domain example.com on > ipa.example.com > >> - DNS server sub.example.com on > host.sub.example.com > >> - client.example.com with IP-nr off > ipa.example.com in resolv.conf > >> - an A record for client.sub.example.com > in DNS server host.sub.example.com > > >> > >> Problem: I cannot resolve the address of client.sub.example.com > from > >> client.example.com . > >> > >> I have tried all kinds of configs: > >> 1. Configured global forwarding in named.conf on ipa.example.com > > >> 2. Configured zone forwarding in named.conf on ipa.example.com > for zone > >> sub.example.com > >> 3. Configured global forwarding in IPA server > >> 4. Add a zone sub.example.conf in IPA and configured forwarding on that > >> zone. > >> > >> Nothing works. I keep getting NXDOMAIN when doing a dig. If I query > the DNS > >> server on host.sub.example.com directly, > it resolves. > >> > >> Using RHEL6.3 on all hosts. > >> > >> I found an old bugzilla on recursion problems. in namd.conf recursion is > >> allowed for "any". > > > > I think it is not a recursion issue, but related to delegation. Since > > the IPA DNS server on ipa.example.com thinks he is > > responsible/authoritative for the whole example.com > he would also try to > > handle request for sub.example.com . > > > > You have to tell the DNS serve explicitly that there is another DNS > > server for sub.example.com by calling: > > > > ipa dnsrecord-add example.com subdns > --a-ip-address=1.2.3.4 > > ipa dnsrecord-add example.com sub --ns-hostname=subdns > > > > Please note that the DNS server for sub.example.com > is now called > > 'subdns.example.com ' since a name from the > example.com domain is needed > > because otherwise the name cannot be resolved. > > > > HTH > > > > bye, > > Sumit > > > >> > >> I'm not sure if this is a IPA or a DNS issue.. > >> > >> Fred > > Hello, > > please don't use forwarders, just create a NS+A record pair for > "sub.example.com " domain in IPA DNS as Sumit > wrote above. > > Current version seems to have some problems with forwarders, I will > investigate it. > > Configuration with forwarders are often confusing, please don't use them if it > is not necessary. From giomac at gmail.com Tue Oct 23 09:54:17 2012 From: giomac at gmail.com (George Machitidze) Date: Tue, 23 Oct 2012 13:54:17 +0400 Subject: [Freeipa-users] Proven procedure for resetting admin password from CLI In-Reply-To: <1350567003.30610.94.camel@willson.li.ssimo.org> References: <1350567003.30610.94.camel@willson.li.ssimo.org> Message-ID: Hi Thanks for reply Unfortunately my VM is already destroyed. I'm currently experimenting with some configurations - I'll try to check again after and update with results via this thread. Best regards, George Machitidze On Thu, Oct 18, 2012 at 5:30 PM, Simo Sorce wrote: > On Thu, 2012-10-18 at 14:49 +0400, George Machitidze wrote: > > Hello > > > > > > I want to reset admin password for FreeIPA 2.x (F17), but I couldn't > > find working procedure for that - all what I've found failed. > > Do we have any verified method/docs? > > ipa passwd or kpasswd should work just fine. > you should also be able to use ldappasswd if you prefer that. > > Can you tell exactly what failed an how ? > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Oct 23 11:02:29 2012 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 23 Oct 2012 13:02:29 +0200 Subject: [Freeipa-users] Announcing FreeIPA v2.2.1 Release Message-ID: <50867945.4010906@redhat.com> The FreeIPA team is proud to announce a bug fix release FreeIPA v2.2.1. It can be downloaded from http://www.freeipa.org/page/Downloads. A build is on the way to updates-testing for Fedora 17. Fedora 15 and 16 are not supported by FreeIPA 2.2.1 due to missing dependencies. == Highlights in 2.2.1 == * New Firefox extension able to configure browser for Kerberos support. The extension is required in Firefox 15 and later as updates to Firefox configuration via signed code is no longer supported * Web UI Host page fixed to work with disabled DNS * Client SSH configuration has been fixed to use GlobalKnownHostsFile instead of GlobalKnownHostsFile2 in as the latter has been deprecated in OpenSSH 5.9 == Upgrading == An IPA server can be upgraded simply by installing updated rpms. The server does not need to be shut down in advance. If you have multiple servers you may upgrade them one at a time. It is expected that all servers will be upgraded in a relatively short period (days or weeks not months). They should be able to co-exist peacefully but new features will not be available on old servers and enrolling a new client against an old server will result in the SSH keys not being uploaded. Downgrading a server once upgraded is not supported. == Feedback == Please provide comments, bugs and other feedback via the freeipa-devel mailing list: http://www.redhat.com/mailman/listinfo/freeipa-devel == Detailed Changelog since 2.2.0 == Endi Sukma Dewata (1): * Fixed boot.ldif permission. Jan Cholasta (1): * SSH configuration fixes. Martin Kosek (1): * Become IPA 2.2.1 Petr Viktorin (2): * replica-install: Don't copy Firefox config extension files if they're not in the replica file * Create Firefox extension on upgrade and replica-install Petr Vobornik (8): * Host page fixed to work with disabled DNS support * Fix jquery error when using '??' in a pkey * Kerberos authentication extension * Kerberos authentication extension makefiles * Build and installation of Kerberos authentication extension * Configuration pages changed to use new FF extension * Add mime type to httpd ipa.conf for xpi extension * RPM spec fix for ffconfig.js and ffconfig_page.js Rob Crittenden (2): * Check for locked-out user before incrementing lastfail. * Index the fqdn attribute. Simo Sorce (2): * Fix migration code password setting. * Add support for disabling KDC writes From giomac at gmail.com Tue Oct 23 11:50:18 2012 From: giomac at gmail.com (George Machitidze) Date: Tue, 23 Oct 2012 15:50:18 +0400 Subject: [Freeipa-users] Passsync details missing Message-ID: Hi I'm testing MS AD integration, following document contents http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync secretpwd", but nowhere's said if user has to be created on MS AD side, or if any package has to be installed. How to continue? Best regards, George Machitidze From dpal at redhat.com Tue Oct 23 16:16:11 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 23 Oct 2012 12:16:11 -0400 Subject: [Freeipa-users] Passsync details missing In-Reply-To: References: Message-ID: <5086C2CB.6050709@redhat.com> On 10/23/2012 07:50 AM, George Machitidze wrote: > Hi > > I'm testing MS AD integration, following document contents > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html > > For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync > secretpwd", but nowhere's said if user has to be created on MS AD > side, or if any package has to be installed. It is implied that this is the password of the administrative user that you already have on the AD side. > How to continue? > > Best regards, > George Machitidze > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Oct 23 16:47:50 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Oct 2012 12:47:50 -0400 Subject: [Freeipa-users] Passsync details missing In-Reply-To: <5086C2CB.6050709@redhat.com> References: <5086C2CB.6050709@redhat.com> Message-ID: <1351010870.30610.221.camel@willson.li.ssimo.org> On Tue, 2012-10-23 at 12:16 -0400, Dmitri Pal wrote: > On 10/23/2012 07:50 AM, George Machitidze wrote: > > Hi > > > > I'm testing MS AD integration, following document contents > > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html > > > > For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync > > secretpwd", but nowhere's said if user has to be created on MS AD > > side, or if any package has to be installed. > > It is implied that this is the password of the administrative user that > you already have on the AD side. Nope, the password provided with that switch is used to create a special sysaccount user named 'passsync' in IPA. the DN of the user is: uid=passsync,cn=sysaccount,cn=etc,$suffix This user is used by the Windows Passsync plugin installed on AD domain controllers. So this password is what you need to use when configuring the Passync plugin together with the above dn template. Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Tue Oct 23 17:13:10 2012 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 23 Oct 2012 13:13:10 -0400 Subject: [Freeipa-users] Passsync details missing In-Reply-To: <1351010870.30610.221.camel@willson.li.ssimo.org> References: <5086C2CB.6050709@redhat.com> <1351010870.30610.221.camel@willson.li.ssimo.org> Message-ID: <5086D026.7030405@redhat.com> On 10/23/2012 12:47 PM, Simo Sorce wrote: > On Tue, 2012-10-23 at 12:16 -0400, Dmitri Pal wrote: >> On 10/23/2012 07:50 AM, George Machitidze wrote: >>> Hi >>> >>> I'm testing MS AD integration, following document contents >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html >>> >>> For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync >>> secretpwd", but nowhere's said if user has to be created on MS AD >>> side, or if any package has to be installed. >> It is implied that this is the password of the administrative user that >> you already have on the AD side. > Nope, the password provided with that switch is used to create a special > sysaccount user named 'passsync' in IPA. > the DN of the user is: uid=passsync,cn=sysaccount,cn=etc,$suffix > > This user is used by the Windows Passsync plugin installed on AD domain > controllers. So this password is what you need to use when configuring > the Passync plugin together with the above dn template. > > Simo. > Then we should update our docs. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From simo at redhat.com Tue Oct 23 17:22:46 2012 From: simo at redhat.com (Simo Sorce) Date: Tue, 23 Oct 2012 13:22:46 -0400 Subject: [Freeipa-users] Passsync details missing In-Reply-To: <5086D026.7030405@redhat.com> References: <5086C2CB.6050709@redhat.com> <1351010870.30610.221.camel@willson.li.ssimo.org> <5086D026.7030405@redhat.com> Message-ID: <1351012966.30610.222.camel@willson.li.ssimo.org> On Tue, 2012-10-23 at 13:13 -0400, Dmitri Pal wrote: > On 10/23/2012 12:47 PM, Simo Sorce wrote: > > On Tue, 2012-10-23 at 12:16 -0400, Dmitri Pal wrote: > >> On 10/23/2012 07:50 AM, George Machitidze wrote: > >>> Hi > >>> > >>> I'm testing MS AD integration, following document contents > >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html > >>> > >>> For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync > >>> secretpwd", but nowhere's said if user has to be created on MS AD > >>> side, or if any package has to be installed. > >> It is implied that this is the password of the administrative user that > >> you already have on the AD side. > > Nope, the password provided with that switch is used to create a special > > sysaccount user named 'passsync' in IPA. > > the DN of the user is: uid=passsync,cn=sysaccount,cn=etc,$suffix > > > > This user is used by the Windows Passsync plugin installed on AD domain > > controllers. So this password is what you need to use when configuring > > the Passync plugin together with the above dn template. > > > > Simo. > > > Then we should update our docs. Yes we should clarify our manpage by making it say: "Password for the IPA system user used by the Windows Passync plugin to synchronize passwords" Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Tue Oct 23 17:37:13 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 23 Oct 2012 13:37:13 -0400 Subject: [Freeipa-users] Passsync details missing In-Reply-To: <5086D026.7030405@redhat.com> References: <5086C2CB.6050709@redhat.com> <1351010870.30610.221.camel@willson.li.ssimo.org> <5086D026.7030405@redhat.com> Message-ID: <5086D5C9.1080503@redhat.com> Dmitri Pal wrote: > On 10/23/2012 12:47 PM, Simo Sorce wrote: >> On Tue, 2012-10-23 at 12:16 -0400, Dmitri Pal wrote: >>> On 10/23/2012 07:50 AM, George Machitidze wrote: >>>> Hi >>>> >>>> I'm testing MS AD integration, following document contents >>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/managing-sync-agmt.html >>>> >>>> For 8.4.2. (Creating Synchronization Agreements) we've got "--passsync >>>> secretpwd", but nowhere's said if user has to be created on MS AD >>>> side, or if any package has to be installed. >>> It is implied that this is the password of the administrative user that >>> you already have on the AD side. >> Nope, the password provided with that switch is used to create a special >> sysaccount user named 'passsync' in IPA. >> the DN of the user is: uid=passsync,cn=sysaccount,cn=etc,$suffix >> >> This user is used by the Windows Passsync plugin installed on AD domain >> controllers. So this password is what you need to use when configuring >> the Passync plugin together with the above dn template. >> >> Simo. >> > Then we should update our docs. > https://fedorahosted.org/freeipa/ticket/3208 From giomac at gmail.com Wed Oct 24 10:51:30 2012 From: giomac at gmail.com (George Machitidze) Date: Wed, 24 Oct 2012 14:51:30 +0400 Subject: [Freeipa-users] SHA-1 certificate support Message-ID: Hello When external CA is used ipa-server-install generates ipa.csr certificate request file, requesting SHA-2 certificate. Is there any working way to make it work with SHA-1, is that fine from point of view of functionality (forget about security). Best regards, George Machitidze From Steven.Jones at vuw.ac.nz Wed Oct 24 22:37:26 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 24 Oct 2012 22:37:26 +0000 Subject: [Freeipa-users] ipa user-find Message-ID: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz> When doing the above it only returns 2000, I have 6000 How to get it to return 6000+? regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From rcritten at redhat.com Thu Oct 25 02:40:39 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Oct 2012 22:40:39 -0400 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5088A6A7.2010707@redhat.com> Steven Jones wrote: > When doing the above it only returns 2000, I have 6000 > > How to get it to return 6000+? There are two size limits. One is a global limit in 389-ds-base, nsslapd-sizelimit which defaults to 2000. IPA has its own search limit which you can also set globally, or override it on the command line (which I'll do below). You'll need to bind as Directory Manager to change nsslapd-sizelimit then you can run: ipa user-find --sizelimit=8000 I don't believe any services need to be restarted for this to take effect. We generally discourage enumerating all entries for performance reasons which is why by default the IPA size limit is 100. rob From Steven.Jones at vuw.ac.nz Thu Oct 25 02:57:59 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 25 Oct 2012 02:57:59 +0000 Subject: [Freeipa-users] ipa user-find In-Reply-To: <5088A6A7.2010707@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, How do I bind as the directory manager? Ive tried and I cant figure out how. and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 25 October 2012 3:40 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ipa user-find Steven Jones wrote: > When doing the above it only returns 2000, I have 6000 > > How to get it to return 6000+? There are two size limits. One is a global limit in 389-ds-base, nsslapd-sizelimit which defaults to 2000. IPA has its own search limit which you can also set globally, or override it on the command line (which I'll do below). You'll need to bind as Directory Manager to change nsslapd-sizelimit then you can run: ipa user-find --sizelimit=8000 I don't believe any services need to be restarted for this to take effect. We generally discourage enumerating all entries for performance reasons which is why by default the IPA size limit is 100. rob From rcritten at redhat.com Thu Oct 25 03:16:59 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 24 Oct 2012 23:16:59 -0400 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5088AF2B.4070902@redhat.com> Steven Jones wrote: > Hi, > > How do I bind as the directory manager? Ive tried and I cant figure out how. Assuming you're running on the same host as IPA: $ ldapmodify -x -D 'cn=directory manager' -W dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config changetype: modify replace: nsslapd-sizelimit nsslapd-sizelimit: 8000 ^D And yes, that's an extra blank line after 8000. > and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... You'll need to modify the size limit in the IPA configuration screen. IPA Server -> Configuration -> Search size limit rob > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 25 October 2012 3:40 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > Steven Jones wrote: >> When doing the above it only returns 2000, I have 6000 >> >> How to get it to return 6000+? > > There are two size limits. One is a global limit in 389-ds-base, > nsslapd-sizelimit which defaults to 2000. > > IPA has its own search limit which you can also set globally, or > override it on the command line (which I'll do below). > > You'll need to bind as Directory Manager to change nsslapd-sizelimit > then you can run: > > ipa user-find --sizelimit=8000 > > I don't believe any services need to be restarted for this to take effect. > > We generally discourage enumerating all entries for performance reasons > which is why by default the IPA size limit is 100. > > rob > > > From rmeggins at redhat.com Thu Oct 25 13:16:20 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 25 Oct 2012 07:16:20 -0600 Subject: [Freeipa-users] ipa user-find In-Reply-To: <5088AF2B.4070902@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> <5088AF2B.4070902@redhat.com> Message-ID: <50893BA4.7020806@redhat.com> On 10/24/2012 09:16 PM, Rob Crittenden wrote: > Steven Jones wrote: >> Hi, >> >> How do I bind as the directory manager? Ive tried and I cant figure >> out how. > > Assuming you're running on the same host as IPA: > > $ ldapmodify -x -D 'cn=directory manager' -W > dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config > changetype: modify > replace: nsslapd-sizelimit > nsslapd-sizelimit: 8000 > > ^D > > And yes, that's an extra blank line after 8000. ? chaining database? Does IPA use this? Don't you mean dn: cn=config ? > >> and how do I get the web ui to return all users so I can see if the >> winsync is working , its a test bed so I need to do a side by side >> comparison.... > > You'll need to modify the size limit in the IPA configuration screen. > IPA Server -> Configuration -> Search size limit > > rob > >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Thursday, 25 October 2012 3:40 p.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] ipa user-find >> >> Steven Jones wrote: >>> When doing the above it only returns 2000, I have 6000 >>> >>> How to get it to return 6000+? >> >> There are two size limits. One is a global limit in 389-ds-base, >> nsslapd-sizelimit which defaults to 2000. >> >> IPA has its own search limit which you can also set globally, or >> override it on the command line (which I'll do below). >> >> You'll need to bind as Directory Manager to change nsslapd-sizelimit >> then you can run: >> >> ipa user-find --sizelimit=8000 >> >> I don't believe any services need to be restarted for this to take >> effect. >> >> We generally discourage enumerating all entries for performance reasons >> which is why by default the IPA size limit is 100. >> >> rob >> >> >> > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rcritten at redhat.com Thu Oct 25 13:23:45 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 25 Oct 2012 09:23:45 -0400 Subject: [Freeipa-users] ipa user-find In-Reply-To: <50893BA4.7020806@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> <5088AF2B.4070902@redhat.com> <50893BA4.7020806@redhat.com> Message-ID: <50893D61.8060305@redhat.com> Rich Megginson wrote: > On 10/24/2012 09:16 PM, Rob Crittenden wrote: >> Steven Jones wrote: >>> Hi, >>> >>> How do I bind as the directory manager? Ive tried and I cant figure >>> out how. >> >> Assuming you're running on the same host as IPA: >> >> $ ldapmodify -x -D 'cn=directory manager' -W >> dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config >> changetype: modify >> replace: nsslapd-sizelimit >> nsslapd-sizelimit: 8000 >> >> ^D >> >> And yes, that's an extra blank line after 8000. > > ? chaining database? Does IPA use this? > > Don't you mean dn: cn=config ? Yes, of course I did. Sorry, this is what I get for responding too quickly. rob From pspacek at redhat.com Thu Oct 25 13:43:43 2012 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 25 Oct 2012 15:43:43 +0200 Subject: [Freeipa-users] ipa user-find In-Reply-To: <50893D61.8060305@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> <5088AF2B.4070902@redhat.com> <50893BA4.7020806@redhat.com> <50893D61.8060305@redhat.com> Message-ID: <5089420F.9000304@redhat.com> On 10/25/2012 03:23 PM, Rob Crittenden wrote: > Rich Megginson wrote: >> On 10/24/2012 09:16 PM, Rob Crittenden wrote: >>> Steven Jones wrote: >>>> Hi, >>>> >>>> How do I bind as the directory manager? Ive tried and I cant figure >>>> out how. >>> >>> Assuming you're running on the same host as IPA: >>> >>> $ ldapmodify -x -D 'cn=directory manager' -W >>> dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config >>> changetype: modify >>> replace: nsslapd-sizelimit >>> nsslapd-sizelimit: 8000 >>> >>> ^D I would recommend to modify user-specific settings rather that global settings. E.g. for admin you can set "unlimited" size with following LDIF snippet: dn: uid=admin,cn=users,cn=accounts,dc=e,dc=test changetype: modify add: nsSizeLimit nsSizeLimit: -1 Also other limits are enforced by 389 DS. All of them can be disabled with "-1" value: nsIdleTimeout: -1 nsLookThroughLimit: -1 nsSizeLimit: -1 nsTimeLimit: -1 Please note different attribute names for user-specific and global-setting attributes. Whole procedure and attribute meaning is described in https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/8.1/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html -- Petr^2 Spacek >>> >>> And yes, that's an extra blank line after 8000. >> >> ? chaining database? Does IPA use this? >> >> Don't you mean dn: cn=config ? > > Yes, of course I did. Sorry, this is what I get for responding too quickly. > > rob From sakodak at gmail.com Thu Oct 25 15:49:51 2012 From: sakodak at gmail.com (KodaK) Date: Thu, 25 Oct 2012 10:49:51 -0500 Subject: [Freeipa-users] Different primary group on different machines. Message-ID: I've been having users use the "newgrp" command to change their primary group on different machines. I've poked around in the docs a bit and I don't see this addressed. I know, I know: "if it works, use it" -- but I'm wondering if I'm just missing a way to do it with IPA, or if there's another way to do it that might be better. Any thoughts? Thanks, --Jason -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 From dpal at redhat.com Thu Oct 25 17:35:36 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Oct 2012 13:35:36 -0400 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: References: Message-ID: <50897868.4070907@redhat.com> On 10/25/2012 11:49 AM, KodaK wrote: > I've been having users use the "newgrp" command to change their > primary group on different machines. > > I've poked around in the docs a bit and I don't see this addressed. I > know, I know: "if it works, use it" -- but I'm wondering if I'm just > missing a way to do it with IPA, or if there's another way to do it > that might be better. > > Any thoughts? > > Thanks, > > --Jason > By reading the description of the command it seems that it works only for local accounts. So I suspect it is not effective in any case when the users come from LDAP and not file. That brings the question: what is the use case and why you need it and subsequently is there any other way to solve the problem you are trying to solve with already existing means in SSSD? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Oct 25 17:39:51 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Oct 2012 13:39:51 -0400 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <50897967.7030905@redhat.com> On 10/24/2012 10:57 PM, Steven Jones wrote: > Hi, > > How do I bind as the directory manager? Ive tried and I cant figure out how. > > and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... It might be much easier to do an ldap search or use IPA command line to get the list of the users and then dump it into a DB or table or something else and then have a simple script that would do a comparison. I am not sure web UI is the best way to do the task at hand. > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 25 October 2012 3:40 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > Steven Jones wrote: >> When doing the above it only returns 2000, I have 6000 >> >> How to get it to return 6000+? > There are two size limits. One is a global limit in 389-ds-base, > nsslapd-sizelimit which defaults to 2000. > > IPA has its own search limit which you can also set globally, or > override it on the command line (which I'll do below). > > You'll need to bind as Directory Manager to change nsslapd-sizelimit > then you can run: > > ipa user-find --sizelimit=8000 > > I don't believe any services need to be restarted for this to take effect. > > We generally discourage enumerating all entries for performance reasons > which is why by default the IPA size limit is 100. > > rob > > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From sakodak at gmail.com Thu Oct 25 19:11:14 2012 From: sakodak at gmail.com (KodaK) Date: Thu, 25 Oct 2012 14:11:14 -0500 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: <50897868.4070907@redhat.com> References: <50897868.4070907@redhat.com> Message-ID: On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal wrote: > On 10/25/2012 11:49 AM, KodaK wrote: >> I've been having users use the "newgrp" command to change their >> primary group on different machines. >> >> I've poked around in the docs a bit and I don't see this addressed. I >> know, I know: "if it works, use it" -- but I'm wondering if I'm just >> missing a way to do it with IPA, or if there's another way to do it >> that might be better. >> >> Any thoughts? >> >> Thanks, >> >> --Jason >> > By reading the description of the command it seems that it works only > for local accounts. > So I suspect it is not effective in any case when the users come from > LDAP and not file. > > That brings the question: what is the use case and why you need it and > subsequently is there any other way to solve the problem you are trying > to solve with already existing means in SSSD? > I have users that need different primary groups on different machines. The newgrp command works -- unfortunately putting it in a login script is a bad thing because newgrp reads those same login scripts, creating an infinite loop. We have many different development groups, but people can be members of multiple groups. For collaboration, they'd like it when creating a file to have that file have a group ownership of "foo" on machine-A, but "bar" on machine-B. I'd like to help the end users do this themselves so that I don't have to maintain separate files on each machine (one of the reasons I put in IPA in the first place. :) ) Thanks, --Jason From dpal at redhat.com Thu Oct 25 19:30:27 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Oct 2012 15:30:27 -0400 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: References: <50897868.4070907@redhat.com> Message-ID: <50899353.10403@redhat.com> On 10/25/2012 03:11 PM, KodaK wrote: > On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal wrote: >> On 10/25/2012 11:49 AM, KodaK wrote: >>> I've been having users use the "newgrp" command to change their >>> primary group on different machines. >>> >>> I've poked around in the docs a bit and I don't see this addressed. I >>> know, I know: "if it works, use it" -- but I'm wondering if I'm just >>> missing a way to do it with IPA, or if there's another way to do it >>> that might be better. >>> >>> Any thoughts? >>> >>> Thanks, >>> >>> --Jason >>> >> By reading the description of the command it seems that it works only >> for local accounts. >> So I suspect it is not effective in any case when the users come from >> LDAP and not file. >> >> That brings the question: what is the use case and why you need it and >> subsequently is there any other way to solve the problem you are trying >> to solve with already existing means in SSSD? >> > I have users that need different primary groups on different machines. > The newgrp command works -- unfortunately putting it in a login > script is a bad thing because newgrp reads those same login scripts, > creating an infinite loop. > > We have many different development groups, but people can be members > of multiple groups. For collaboration, they'd like it when creating a > file to have that file have a group ownership of "foo" on machine-A, > but "bar" on machine-B. I'd like to help the end users do this > themselves so that I don't have to maintain separate files on each > machine (one of the reasons I put in IPA in the first place. :) ) > > Thanks, > > --Jason I see it to be solvable in two different ways. One centrally in IPA. Something like an extra attribute attached to HBAC rule that would denote the alternative default group. This is just from top of my head. I already see problems with this approach but anyways this is one direction. A different option is to have a local override in the sssd.conf and make SSSD swap primary group for the user but then you would have to configure it per user - not a nice approach too. Hmmm may be some kind of the sss_chache related utility that would update cache with the preferred GID, that would work as a command but has other implications - dealing with fast cache and server side changes that might override the value... Anyways not an easy fix. Can you please file an RFE? Would you be able to contribute some code for such feature? -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From Steven.Jones at vuw.ac.nz Thu Oct 25 19:55:31 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 25 Oct 2012 19:55:31 +0000 Subject: [Freeipa-users] Improving user manual. Message-ID: <833D8E48405E064EBC54C84EC6B36E40546FA090@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, One thing that has plagued me for the last 9 months is trying to fault find why something doesnt work when setting up or in operation. Looking at each section, say the passsync I think it would be useful to have a troubleshooting guide at the end of each piece of work. So if say passsync doesnt work, start by checking logs, a b and c....a successful transfer should look like this "etc etc" Also improving the error messages. regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 From Steven.Jones at vuw.ac.nz Thu Oct 25 20:37:48 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 25 Oct 2012 20:37:48 +0000 Subject: [Freeipa-users] ipa user-find In-Reply-To: <5088AF2B.4070902@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088AF2B.4070902@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, Ive tried, dn: cn=default instance config,cn=config,cn=plugins and, dn: cn=default instance config,cn=config,cn=plugins,cn=config and get no such object (32) regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rob Crittenden [rcritten at redhat.com] Sent: Thursday, 25 October 2012 4:16 p.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ipa user-find Steven Jones wrote: > Hi, > > How do I bind as the directory manager? Ive tried and I cant figure out how. Assuming you're running on the same host as IPA: $ ldapmodify -x -D 'cn=directory manager' -W dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config changetype: modify replace: nsslapd-sizelimit nsslapd-sizelimit: 8000 ^D And yes, that's an extra blank line after 8000. > and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... You'll need to modify the size limit in the IPA configuration screen. IPA Server -> Configuration -> Search size limit rob > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 25 October 2012 3:40 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > Steven Jones wrote: >> When doing the above it only returns 2000, I have 6000 >> >> How to get it to return 6000+? > > There are two size limits. One is a global limit in 389-ds-base, > nsslapd-sizelimit which defaults to 2000. > > IPA has its own search limit which you can also set globally, or > override it on the command line (which I'll do below). > > You'll need to bind as Directory Manager to change nsslapd-sizelimit > then you can run: > > ipa user-find --sizelimit=8000 > > I don't believe any services need to be restarted for this to take effect. > > We generally discourage enumerating all entries for performance reasons > which is why by default the IPA size limit is 100. > > rob > > > From rmeggins at redhat.com Thu Oct 25 20:44:10 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 25 Oct 2012 14:44:10 -0600 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088AF2B.4070902@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5089A49A.2060400@redhat.com> On 10/25/2012 02:37 PM, Steven Jones wrote: > Hi, > > Ive tried, > > dn: cn=default instance config,cn=config,cn=plugins > > and, > > dn: cn=default instance config,cn=config,cn=plugins,cn=config Try dn: cn=config > > and get no such object (32) > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 25 October 2012 4:16 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > Steven Jones wrote: >> Hi, >> >> How do I bind as the directory manager? Ive tried and I cant figure out how. > Assuming you're running on the same host as IPA: > > $ ldapmodify -x -D 'cn=directory manager' -W > dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config > changetype: modify > replace: nsslapd-sizelimit > nsslapd-sizelimit: 8000 > > ^D > > And yes, that's an extra blank line after 8000. > >> and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... > You'll need to modify the size limit in the IPA configuration screen. > IPA Server -> Configuration -> Search size limit > > rob > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Thursday, 25 October 2012 3:40 p.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] ipa user-find >> >> Steven Jones wrote: >>> When doing the above it only returns 2000, I have 6000 >>> >>> How to get it to return 6000+? >> There are two size limits. One is a global limit in 389-ds-base, >> nsslapd-sizelimit which defaults to 2000. >> >> IPA has its own search limit which you can also set globally, or >> override it on the command line (which I'll do below). >> >> You'll need to bind as Directory Manager to change nsslapd-sizelimit >> then you can run: >> >> ipa user-find --sizelimit=8000 >> >> I don't believe any services need to be restarted for this to take effect. >> >> We generally discourage enumerating all entries for performance reasons >> which is why by default the IPA size limit is 100. >> >> rob >> >> >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From Steven.Jones at vuw.ac.nz Thu Oct 25 20:30:05 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 25 Oct 2012 20:30:05 +0000 Subject: [Freeipa-users] ipa user-find In-Reply-To: <50893BA4.7020806@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz> <5088AF2B.4070902@redhat.com>,<50893BA4.7020806@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546FA0AB@STAWINCOX10MBX1.staff.vuw.ac.nz> 8><--------- > >> and how do I get the web ui to return all users so I can see if the >> winsync is working , its a test bed so I need to do a side by side >> comparison.... > > You'll need to modify the size limit in the IPA configuration screen. > IPA Server -> Configuration -> Search size limit > > rob I have set 10000 vi the command line and the above shows that but it still returns only 2000 entries. regards From Steven.Jones at vuw.ac.nz Thu Oct 25 20:46:30 2012 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 25 Oct 2012 20:46:30 +0000 Subject: [Freeipa-users] ipa user-find In-Reply-To: <5089A49A.2060400@redhat.com> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088AF2B.4070902@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089A49A.2060400@redhat.com> Message-ID: <833D8E48405E064EBC54C84EC6B36E40546FA0D8@STAWINCOX10MBX1.staff.vuw.ac.nz> Hi, yes figured it.... even at 20000 Im still getting an administrative size limit exceeded (11) :( regards Steven Jones Technical Specialist - Linux RHCE Victoria University, Wellington, NZ 0064 4 463 6272 ________________________________________ From: Rich Megginson [rmeggins at redhat.com] Sent: Friday, 26 October 2012 9:44 a.m. To: Steven Jones Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] ipa user-find On 10/25/2012 02:37 PM, Steven Jones wrote: > Hi, > > Ive tried, > > dn: cn=default instance config,cn=config,cn=plugins > > and, > > dn: cn=default instance config,cn=config,cn=plugins,cn=config Try dn: cn=config > > and get no such object (32) > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rob Crittenden [rcritten at redhat.com] > Sent: Thursday, 25 October 2012 4:16 p.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > Steven Jones wrote: >> Hi, >> >> How do I bind as the directory manager? Ive tried and I cant figure out how. > Assuming you're running on the same host as IPA: > > $ ldapmodify -x -D 'cn=directory manager' -W > dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config > changetype: modify > replace: nsslapd-sizelimit > nsslapd-sizelimit: 8000 > > ^D > > And yes, that's an extra blank line after 8000. > >> and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... > You'll need to modify the size limit in the IPA configuration screen. > IPA Server -> Configuration -> Search size limit > > rob > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Thursday, 25 October 2012 3:40 p.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] ipa user-find >> >> Steven Jones wrote: >>> When doing the above it only returns 2000, I have 6000 >>> >>> How to get it to return 6000+? >> There are two size limits. One is a global limit in 389-ds-base, >> nsslapd-sizelimit which defaults to 2000. >> >> IPA has its own search limit which you can also set globally, or >> override it on the command line (which I'll do below). >> >> You'll need to bind as Directory Manager to change nsslapd-sizelimit >> then you can run: >> >> ipa user-find --sizelimit=8000 >> >> I don't believe any services need to be restarted for this to take effect. >> >> We generally discourage enumerating all entries for performance reasons >> which is why by default the IPA size limit is 100. >> >> rob >> >> >> > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From sakodak at gmail.com Thu Oct 25 21:04:20 2012 From: sakodak at gmail.com (KodaK) Date: Thu, 25 Oct 2012 16:04:20 -0500 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: <50899353.10403@redhat.com> References: <50897868.4070907@redhat.com> <50899353.10403@redhat.com> Message-ID: On Thu, Oct 25, 2012 at 2:30 PM, Dmitri Pal wrote: > On 10/25/2012 03:11 PM, KodaK wrote: >> On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal wrote: >>> On 10/25/2012 11:49 AM, KodaK wrote: >>>> I've been having users use the "newgrp" command to change their >>>> primary group on different machines. >>>> >>>> I've poked around in the docs a bit and I don't see this addressed. I >>>> know, I know: "if it works, use it" -- but I'm wondering if I'm just >>>> missing a way to do it with IPA, or if there's another way to do it >>>> that might be better. >>>> >>>> Any thoughts? >>>> >>>> Thanks, >>>> >>>> --Jason >>>> >>> By reading the description of the command it seems that it works only >>> for local accounts. >>> So I suspect it is not effective in any case when the users come from >>> LDAP and not file. >>> >>> That brings the question: what is the use case and why you need it and >>> subsequently is there any other way to solve the problem you are trying >>> to solve with already existing means in SSSD? >>> >> I have users that need different primary groups on different machines. >> The newgrp command works -- unfortunately putting it in a login >> script is a bad thing because newgrp reads those same login scripts, >> creating an infinite loop. >> >> We have many different development groups, but people can be members >> of multiple groups. For collaboration, they'd like it when creating a >> file to have that file have a group ownership of "foo" on machine-A, >> but "bar" on machine-B. I'd like to help the end users do this >> themselves so that I don't have to maintain separate files on each >> machine (one of the reasons I put in IPA in the first place. :) ) >> >> Thanks, >> >> --Jason > I see it to be solvable in two different ways. > One centrally in IPA. Something like an extra attribute attached to HBAC > rule that would denote the alternative default group. This is just from > top of my head. I already see problems with this approach but anyways > this is one direction. I'd think it would have to be per-user or a separate policy area. "these users" get "this pgrp" on "these servers". > A different option is to have a local override in the sssd.conf and make > SSSD swap primary group for the user but then you would have to > configure it per user - not a nice approach too. > Hmmm may be some kind of the sss_chache related utility that would > update cache with the preferred GID, that would work as a command but > has other implications - dealing with fast cache and server side changes > that might override the value... > > Anyways not an easy fix. Can you please file an RFE? Sure. Where do I do that? :) (I'm kidding, I'll google it.) > Would you be able to contribute some code for such feature? I'd love to say I could, but I'm not really a coder, and my day job has me working 50-60 hours a week as it is. And when I say "I'd love to" I really mean it. I'd rather be doing that than my day job. :) --Jason From rmeggins at redhat.com Thu Oct 25 21:24:51 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 25 Oct 2012 15:24:51 -0600 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546FA0D8@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088AF2B.4070902@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089A49A.2060400@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0D8@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5089AE23.8000706@redhat.com> On 10/25/2012 02:46 PM, Steven Jones wrote: > Hi, > > yes figured it.... > > even at 20000 Im still getting an administrative size limit exceeded (11) This means you're either hitting the lookthroughlimit and/or the idlistscanlimit. The idlistscanlimit is described here - https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#nsslapd_idlistscanlimit I suggest changing the value to be 2 times as large as the number of entries in your database, just to be safe: ldapmodify -x -D "cn=directory manager" -W < > :( > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rich Megginson [rmeggins at redhat.com] > Sent: Friday, 26 October 2012 9:44 a.m. > To: Steven Jones > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] ipa user-find > > On 10/25/2012 02:37 PM, Steven Jones wrote: >> Hi, >> >> Ive tried, >> >> dn: cn=default instance config,cn=config,cn=plugins >> >> and, >> >> dn: cn=default instance config,cn=config,cn=plugins,cn=config > Try > dn: cn=config >> and get no such object (32) >> >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rob Crittenden [rcritten at redhat.com] >> Sent: Thursday, 25 October 2012 4:16 p.m. >> To: Steven Jones >> Cc: freeipa-users at redhat.com >> Subject: Re: [Freeipa-users] ipa user-find >> >> Steven Jones wrote: >>> Hi, >>> >>> How do I bind as the directory manager? Ive tried and I cant figure out how. >> Assuming you're running on the same host as IPA: >> >> $ ldapmodify -x -D 'cn=directory manager' -W >> dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config >> changetype: modify >> replace: nsslapd-sizelimit >> nsslapd-sizelimit: 8000 >> >> ^D >> >> And yes, that's an extra blank line after 8000. >> >>> and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... >> You'll need to modify the size limit in the IPA configuration screen. >> IPA Server -> Configuration -> Search size limit >> >> rob >> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rob Crittenden [rcritten at redhat.com] >>> Sent: Thursday, 25 October 2012 3:40 p.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] ipa user-find >>> >>> Steven Jones wrote: >>>> When doing the above it only returns 2000, I have 6000 >>>> >>>> How to get it to return 6000+? >>> There are two size limits. One is a global limit in 389-ds-base, >>> nsslapd-sizelimit which defaults to 2000. >>> >>> IPA has its own search limit which you can also set globally, or >>> override it on the command line (which I'll do below). >>> >>> You'll need to bind as Directory Manager to change nsslapd-sizelimit >>> then you can run: >>> >>> ipa user-find --sizelimit=8000 >>> >>> I don't believe any services need to be restarted for this to take effect. >>> >>> We generally discourage enumerating all entries for performance reasons >>> which is why by default the IPA size limit is 100. >>> >>> rob >>> >>> >>> >> >> >> _______________________________________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-users > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From natxo.asenjo at gmail.com Thu Oct 25 21:33:54 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 25 Oct 2012 23:33:54 +0200 Subject: [Freeipa-users] how to unlock an account from ldap Message-ID: hi, how can I unlock the admin password using ldap commands? I misstyped the password using kinit a couple of times and now the account is locked. I have already changed the passwd using the command in https://www.redhat.com/archives/freeipa-users/2011-May/msg00144.html, but I still cannot login as admin. Thanks in advance. -- Groeten, natxo From natxo.asenjo at gmail.com Thu Oct 25 21:39:01 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 25 Oct 2012 23:39:01 +0200 Subject: [Freeipa-users] how to unlock an account from ldap In-Reply-To: References: Message-ID: On Thu, Oct 25, 2012 at 11:33 PM, Natxo Asenjo wrote: > hi, > > how can I unlock the admin password using ldap commands? I misstyped > the password using kinit a couple of times and now the account is > locked. > > I have already changed the passwd using the command in > https://www.redhat.com/archives/freeipa-users/2011-May/msg00144.html, > but I still cannot login as admin. never mind, there appears to be a lockout time and now it works. -- natxo From dpal at redhat.com Thu Oct 25 22:07:05 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Oct 2012 18:07:05 -0400 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: References: <50897868.4070907@redhat.com> <50899353.10403@redhat.com> Message-ID: <5089B809.1040607@redhat.com> On 10/25/2012 05:04 PM, KodaK wrote: > On Thu, Oct 25, 2012 at 2:30 PM, Dmitri Pal wrote: >> On 10/25/2012 03:11 PM, KodaK wrote: >>> On Thu, Oct 25, 2012 at 12:35 PM, Dmitri Pal wrote: >>>> On 10/25/2012 11:49 AM, KodaK wrote: >>>>> I've been having users use the "newgrp" command to change their >>>>> primary group on different machines. >>>>> >>>>> I've poked around in the docs a bit and I don't see this addressed. I >>>>> know, I know: "if it works, use it" -- but I'm wondering if I'm just >>>>> missing a way to do it with IPA, or if there's another way to do it >>>>> that might be better. >>>>> >>>>> Any thoughts? >>>>> >>>>> Thanks, >>>>> >>>>> --Jason >>>>> >>>> By reading the description of the command it seems that it works only >>>> for local accounts. >>>> So I suspect it is not effective in any case when the users come from >>>> LDAP and not file. >>>> >>>> That brings the question: what is the use case and why you need it and >>>> subsequently is there any other way to solve the problem you are trying >>>> to solve with already existing means in SSSD? >>>> >>> I have users that need different primary groups on different machines. >>> The newgrp command works -- unfortunately putting it in a login >>> script is a bad thing because newgrp reads those same login scripts, >>> creating an infinite loop. >>> >>> We have many different development groups, but people can be members >>> of multiple groups. For collaboration, they'd like it when creating a >>> file to have that file have a group ownership of "foo" on machine-A, >>> but "bar" on machine-B. I'd like to help the end users do this >>> themselves so that I don't have to maintain separate files on each >>> machine (one of the reasons I put in IPA in the first place. :) ) >>> >>> Thanks, >>> >>> --Jason >> I see it to be solvable in two different ways. >> One centrally in IPA. Something like an extra attribute attached to HBAC >> rule that would denote the alternative default group. This is just from >> top of my head. I already see problems with this approach but anyways >> this is one direction. > I'd think it would have to be per-user or a separate policy area. > "these users" get "this pgrp" on "these servers". > >> A different option is to have a local override in the sssd.conf and make >> SSSD swap primary group for the user but then you would have to >> configure it per user - not a nice approach too. >> Hmmm may be some kind of the sss_chache related utility that would >> update cache with the preferred GID, that would work as a command but >> has other implications - dealing with fast cache and server side changes >> that might override the value... >> >> Anyways not an easy fix. Can you please file an RFE? > Sure. Where do I do that? :) (I'm kidding, I'll google it.) > >> Would you be able to contribute some code for such feature? > I'd love to say I could, but I'm not really a coder, and my day job > has me working 50-60 hours a week as it is. And when I say "I'd love > to" I really mean it. I'd rather be doing that than my day job. :) > > --Jason Thank you for filing a ticket. I suspect Google did its part... :-) So you prefer it centrally managed. Well... Right now it seems like a very corner case and with a workaround as you mentioned so the best opportunity to make it implemented is to actually find someone to contribute the code. I suspect it will be triaged as deferred at our next ticket triage meeting which means that we will gladly accept patches but would not do the work ourselves. The only other way to bump its priority is bring into the conversation other deployments that are looking at the similar functionality. -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From dpal at redhat.com Thu Oct 25 22:09:52 2012 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 25 Oct 2012 18:09:52 -0400 Subject: [Freeipa-users] Improving user manual. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546FA090@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546FA090@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <5089B8B0.3060607@redhat.com> On 10/25/2012 03:55 PM, Steven Jones wrote: > Hi, > > One thing that has plagued me for the last 9 months is trying to fault find why something doesnt work when setting up or in operation. Looking at each section, say the passsync I think it would be useful to have a troubleshooting guide at the end of each piece of work. > > So if say passsync doesnt work, start by checking logs, a b and c....a successful transfer should look like this "etc etc" Also improving the error messages. Steven, We are all for it but it would make sense to start small and move forward. Can you be more specific? Let us start with winsync, can you list the issues and situations that you think worth covering in the troubleshooting section? Can you please point us to the specific messages that you think are incomplete or misleading and should be changed? Thanks Dmitri > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ From chorn at fluxcoil.net Fri Oct 26 02:52:12 2012 From: chorn at fluxcoil.net (Christian Horn) Date: Fri, 26 Oct 2012 04:52:12 +0200 Subject: [Freeipa-users] Improving user manual. In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546FA090@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546FA090@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <20121026025212.GA6682@fluxcoil.net> Hi, On Thu, Oct 25, 2012 at 07:55:31PM +0000, Steven Jones wrote: > > One thing that has plagued me for the last 9 months is trying to fault find why something doesnt work when setting up or in operation. Looking at each section, say the passsync I think it would be useful to have a troubleshooting guide at the end of each piece of work. > > So if say passsync doesnt work, start by checking logs, a b and c....a successful transfer should look like this "etc etc" Also improving the error messages. Besides the documentation on freeipa.org there is also quite something already in the Red Hat Customer Center, accessable if you have Red Hat subscriptions. This is not interconnected to the product documentation but as kbase article, best to be searched using search terms in the customer center. cheers, Christian From natxo.asenjo at gmail.com Fri Oct 26 07:07:38 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 26 Oct 2012 09:07:38 +0200 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: References: <50897868.4070907@redhat.com> Message-ID: On Thu, Oct 25, 2012 at 9:11 PM, KodaK wrote: > We have many different development groups, but people can be members > of multiple groups. For collaboration, they'd like it when creating a > file to have that file have a group ownership of "foo" on machine-A, > but "bar" on machine-B. I'd like to help the end users do this > themselves so that I don't have to maintain separate files on each > machine (one of the reasons I put in IPA in the first place. :) ) I think what you need are filesystem acls. With acls you can specify that new files in a dir structure will have predefined default groups so all members of that particular group will be able to modify the files. -- groet, natxo From ondrejv at s3group.cz Fri Oct 26 07:36:44 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 26 Oct 2012 09:36:44 +0200 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: References: <50897868.4070907@redhat.com> Message-ID: <508A3D8C.6030804@s3group.cz> Well, you do not need ACLs for that, just 'chmod g+s ' will do. But in general, I agree, this is insane requirement as nobody would ever think of it in Windows. Not happy w/ a traditional Unix permissions? Go for ACLs. The only pity is that the current Posix-draft hack widely used on all Linuxes is a mess and Rich-acl support is still nowhere in sight :-( Ondrej On 10/26/2012 09:07 AM, Natxo Asenjo wrote: > On Thu, Oct 25, 2012 at 9:11 PM, KodaK wrote: > >> We have many different development groups, but people can be members >> of multiple groups. For collaboration, they'd like it when creating a >> file to have that file have a group ownership of "foo" on machine-A, >> but "bar" on machine-B. I'd like to help the end users do this >> themselves so that I don't have to maintain separate files on each >> machine (one of the reasons I put in IPA in the first place. :) ) > I think what you need are filesystem acls. With acls you can specify > that new files in a dir structure will have predefined default groups > so all members of that particular group will be able to modify the > files. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Fri Oct 26 09:53:26 2012 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 26 Oct 2012 11:53:26 +0200 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: <508A3D8C.6030804@s3group.cz> References: <50897868.4070907@redhat.com> <508A3D8C.6030804@s3group.cz> Message-ID: hi, yes, you are correct :-). Being a recent nfsv4 acls fan has made me forget that. -- Groeten, natxo On Fri, Oct 26, 2012 at 9:36 AM, Ondrej Valousek wrote: > Well, you do not need ACLs for that, just 'chmod g+s ' will do. > But in general, I agree, this is insane requirement as nobody would ever > think of it in Windows. Not happy w/ a traditional Unix permissions? Go for > ACLs. > The only pity is that the current Posix-draft hack widely used on all > Linuxes is a mess and Rich-acl support is still nowhere in sight :-( > > Ondrej > > On 10/26/2012 09:07 AM, Natxo Asenjo wrote: > > On Thu, Oct 25, 2012 at 9:11 PM, KodaK wrote: > > We have many different development groups, but people can be members > of multiple groups. For collaboration, they'd like it when creating a > file to have that file have a group ownership of "foo" on machine-A, > but "bar" on machine-B. I'd like to help the end users do this > themselves so that I don't have to maintain separate files on each > machine (one of the reasons I put in IPA in the first place. :) ) > > I think what you need are filesystem acls. With acls you can specify > that new files in a dir structure will have predefined default groups > so all members of that particular group will be able to modify the > files. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users From rmeggins at redhat.com Fri Oct 26 13:25:43 2012 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 26 Oct 2012 07:25:43 -0600 Subject: [Freeipa-users] ipa user-find In-Reply-To: <833D8E48405E064EBC54C84EC6B36E40546FA21C@STAWINCOX10MBX1.staff.vuw.ac.nz> References: <833D8E48405E064EBC54C84EC6B36E40546F9A24@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088A6A7.2010707@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546F9B1C@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5088AF2B.4070902@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0BA@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089A49A.2060400@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA0D8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089AE23.8000706@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA1CE@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089E5D5.6000905@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA1E8@STAWINCOX10MBX1.staff.vuw.ac.nz>, <5089F3F2.7030709@redhat.com> <833D8E48405E064EBC54C84EC6B36E40546FA21C@STAWINCOX10MBX1.staff.vuw.ac.nz> Message-ID: <508A8F57.2020704@redhat.com> On 10/25/2012 08:33 PM, Steven Jones wrote: > I hadnt restarted but now I have, no difference. > > wc -l says 10000 but every other line is a blank, so yes 5000 seems likely. > > There are just under 6000 AD users....2 servers as this is in the test environment to test winsync and passync....both are working as far as I can tell with the backported rpms. Ok. You may be running into https://fedorahosted.org/389/ticket/446 I believe ipa enables the anonymous limits feature. I suggest increasing these limits. > > regards > > Steven Jones > > Technical Specialist - Linux RHCE > > Victoria University, Wellington, NZ > > 0064 4 463 6272 > > ________________________________________ > From: Rich Megginson [rmeggins at redhat.com] > Sent: Friday, 26 October 2012 3:22 p.m. > To: Steven Jones > Subject: Re: [Freeipa-users] ipa user-find > > On 10/25/2012 07:30 PM, Steven Jones wrote: >> 40000 > Both idlistscanlimit and lookthroughlimit? And you're still hitting a > limit of 5000 entries? > How many entries in your database? > Have you tried restarting dirsrv? > >> regards >> >> Steven Jones >> >> Technical Specialist - Linux RHCE >> >> Victoria University, Wellington, NZ >> >> 0064 4 463 6272 >> >> ________________________________________ >> From: Rich Megginson [rmeggins at redhat.com] >> Sent: Friday, 26 October 2012 2:22 p.m. >> To: Steven Jones >> Subject: Re: [Freeipa-users] ipa user-find >> >> On 10/25/2012 07:14 PM, Steven Jones wrote: >>> Hi, >>> >>> Screenshot of access log output attached. >> You increased the idlistscanlimit and lookthroughlimit? >> >>> regards >>> >>> Steven Jones >>> >>> Technical Specialist - Linux RHCE >>> >>> Victoria University, Wellington, NZ >>> >>> 0064 4 463 6272 >>> >>> ________________________________________ >>> From: Rich Megginson [rmeggins at redhat.com] >>> Sent: Friday, 26 October 2012 10:24 a.m. >>> To: Steven Jones >>> Cc: freeipa-users at redhat.com >>> Subject: Re: [Freeipa-users] ipa user-find >>> >>> On 10/25/2012 02:46 PM, Steven Jones wrote: >>>> Hi, >>>> >>>> yes figured it.... >>>> >>>> even at 20000 Im still getting an administrative size limit exceeded (11) >>> This means you're either hitting the lookthroughlimit and/or the >>> idlistscanlimit. >>> >>> The idlistscanlimit is described here - >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Configuration_Command_and_File_Reference/Database_Plug_in_Attributes.html#nsslapd_idlistscanlimit >>> >>> I suggest changing the value to be 2 times as large as the number of >>> entries in your database, just to be safe: >>> >>> ldapmodify -x -D "cn=directory manager" -W<>> dn: cn=config,cn=ldbm database,cn=plugins,cn=config >>> changetype: modify >>> replace: nsslapd-idlistscanlimit >>> nsslapd-idlistscanlimit: a big number >>> EOF >>> >>> If you still have a problem, it means ipa is doing an unindexed search, >>> and you will have to increase the lookthroughlimit for the ipa admin >>> user. I'm not sure how/where ipa does that. You can set the global >>> limit for all users like this: >>> >>> ldapmodify -x -D "cn=directory manager" -W<>> dn: cn=config >>> changetype: modify >>> replace: nsslapd-lookthroughlimit >>> nsslapd-lookthroughlimit: a big number >>> EOF >>> >>> In case you are wondering what all of this gibberish is >>> >>> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes.html#About_Indexes-Overview_of_the_Searching_Algorithm >>> >>> When the directory server cannot load the IDs of the search results into >>> an ID list, either due to hitting the idlistscanlimit, or the search is >>> unindexed (and therefore there is no index to load the ID list), the >>> server must fall back to searching through every entry in the database. >>> It will only look through nsslapd-lookthroughlimit number of entries >>> before giving up and returning err=11. >>> >>> Can you take a look at the directory server access log at >>> /var/log/dirsrv/slapd-INST/access and look for the corresponding SRCH >>> operation and the RESULT of that search operation and please post it? >>> >>>> :( >>>> >>>> regards >>>> >>>> Steven Jones >>>> >>>> Technical Specialist - Linux RHCE >>>> >>>> Victoria University, Wellington, NZ >>>> >>>> 0064 4 463 6272 >>>> >>>> ________________________________________ >>>> From: Rich Megginson [rmeggins at redhat.com] >>>> Sent: Friday, 26 October 2012 9:44 a.m. >>>> To: Steven Jones >>>> Cc: freeipa-users at redhat.com >>>> Subject: Re: [Freeipa-users] ipa user-find >>>> >>>> On 10/25/2012 02:37 PM, Steven Jones wrote: >>>>> Hi, >>>>> >>>>> Ive tried, >>>>> >>>>> dn: cn=default instance config,cn=config,cn=plugins >>>>> >>>>> and, >>>>> >>>>> dn: cn=default instance config,cn=config,cn=plugins,cn=config >>>> Try >>>> dn: cn=config >>>>> and get no such object (32) >>>>> >>>>> regards >>>>> >>>>> Steven Jones >>>>> >>>>> Technical Specialist - Linux RHCE >>>>> >>>>> Victoria University, Wellington, NZ >>>>> >>>>> 0064 4 463 6272 >>>>> >>>>> ________________________________________ >>>>> From: Rob Crittenden [rcritten at redhat.com] >>>>> Sent: Thursday, 25 October 2012 4:16 p.m. >>>>> To: Steven Jones >>>>> Cc: freeipa-users at redhat.com >>>>> Subject: Re: [Freeipa-users] ipa user-find >>>>> >>>>> Steven Jones wrote: >>>>>> Hi, >>>>>> >>>>>> How do I bind as the directory manager? Ive tried and I cant figure out how. >>>>> Assuming you're running on the same host as IPA: >>>>> >>>>> $ ldapmodify -x -D 'cn=directory manager' -W >>>>> dn: cn=default instance config,cn=chaining database,cn=plugins,cn=config >>>>> changetype: modify >>>>> replace: nsslapd-sizelimit >>>>> nsslapd-sizelimit: 8000 >>>>> >>>>> ^D >>>>> >>>>> And yes, that's an extra blank line after 8000. >>>>> >>>>>> and how do I get the web ui to return all users so I can see if the winsync is working , its a test bed so I need to do a side by side comparison.... >>>>> You'll need to modify the size limit in the IPA configuration screen. >>>>> IPA Server -> Configuration -> Search size limit >>>>> >>>>> rob >>>>> >>>>>> regards >>>>>> >>>>>> Steven Jones >>>>>> >>>>>> Technical Specialist - Linux RHCE >>>>>> >>>>>> Victoria University, Wellington, NZ >>>>>> >>>>>> 0064 4 463 6272 >>>>>> >>>>>> ________________________________________ >>>>>> From: Rob Crittenden [rcritten at redhat.com] >>>>>> Sent: Thursday, 25 October 2012 3:40 p.m. >>>>>> To: Steven Jones >>>>>> Cc: freeipa-users at redhat.com >>>>>> Subject: Re: [Freeipa-users] ipa user-find >>>>>> >>>>>> Steven Jones wrote: >>>>>>> When doing the above it only returns 2000, I have 6000 >>>>>>> >>>>>>> How to get it to return 6000+? >>>>>> There are two size limits. One is a global limit in 389-ds-base, >>>>>> nsslapd-sizelimit which defaults to 2000. >>>>>> >>>>>> IPA has its own search limit which you can also set globally, or >>>>>> override it on the command line (which I'll do below). >>>>>> >>>>>> You'll need to bind as Directory Manager to change nsslapd-sizelimit >>>>>> then you can run: >>>>>> >>>>>> ipa user-find --sizelimit=8000 >>>>>> >>>>>> I don't believe any services need to be restarted for this to take effect. >>>>>> >>>>>> We generally discourage enumerating all entries for performance reasons >>>>>> which is why by default the IPA size limit is 100. >>>>>> >>>>>> rob >>>>>> >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> Freeipa-users mailing list >>>>> Freeipa-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/freeipa-users >>>> _______________________________________________ >>>> Freeipa-users mailing list >>>> Freeipa-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/freeipa-users >> > > From simo at redhat.com Fri Oct 26 13:38:32 2012 From: simo at redhat.com (Simo Sorce) Date: Fri, 26 Oct 2012 09:38:32 -0400 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: <508A3D8C.6030804@s3group.cz> References: <50897868.4070907@redhat.com> <508A3D8C.6030804@s3group.cz> Message-ID: <1351258712.30610.364.camel@willson.li.ssimo.org> On Fri, 2012-10-26 at 09:36 +0200, Ondrej Valousek wrote: > Well, you do not need ACLs for that, just 'chmod g+s ' will > do. This is what makes people ask for changing the GID, which is suboptimal on many accounts. The reason why FreeIPA creates a User Private Group is that the default umask prettyt much everywhere allows the primary group access to new files created, so if the primary group is shared among users it means that by default users cannot expect privacy. This is not nice. > But in general, I agree, this is insane requirement as nobody would > ever think of it in Windows. Not happy w/ a traditional Unix > permissions? Go for ACLs. Default ACLs are very, very useful and enormously more powerful than the sgid bit. I strongly recommend using ACLs for complex default ownership requirements. > The only pity is that the current Posix-draft hack widely used on all > Linuxes is a mess and Rich-acl support is still nowhere in sight :-( Sorry sir, but technically it is the sgid bit that is a gross hack. The Posix draft for ACLs never got final approval, but it is pretty standardized across most OSs, and works fine for any Linux OS that isn;t on ancient kernels. It is also enabled by default on all file systems that matter normally. Rich-ACL, while cool and necessary for NFS ACL and better Windows ACL compatibility will also be much more complex than Posix ACLs, and does not add anything special for the default ACL use case. Simo. -- Simo Sorce * Red Hat, Inc * New York From ondrejv at s3group.cz Fri Oct 26 13:57:14 2012 From: ondrejv at s3group.cz (Ondrej Valousek) Date: Fri, 26 Oct 2012 15:57:14 +0200 Subject: [Freeipa-users] Different primary group on different machines. In-Reply-To: <1351258712.30610.364.camel@willson.li.ssimo.org> References: <50897868.4070907@redhat.com> <508A3D8C.6030804@s3group.cz> <1351258712.30610.364.camel@willson.li.ssimo.org> Message-ID: <508A96BA.5040900@s3group.cz> > Sorry sir, but technically it is the sgid bit that is a gross hack. > The Posix draft for ACLs never got final approval, but it is pretty > standardized across most OSs, and works fine for any Linux OS that isn;t > on ancient kernels. It is also enabled by default on all file systems > that matter normally. I agree with you that the sgid bit is a big hack here and that default ACL rules are much more flexible in general. > Rich-ACL, while cool and necessary for NFS ACL and better Windows ACL > compatibility will also be much more complex than Posix ACLs, and does > not add anything special for the default ACL use case. Frankly speaking, I do not care too much if it is cool or not. What I do care about, is a real cross-platform compatibility necessary for commercial production usage. Posix-draft ACLs never got any final approval and are compatible across most of Linuxes (Windows uses something completely different and SunOS with its zfs filesystem, too). Moreover, there is NFSv4 which also comes with something different as you know and appliances like Netapp NAS does _only_ support NFSv4 ACL semantics. So whereas Posix ACLs might be perfect solution for most users/admins, future is somewhere else. I do not want to start any flame here, I just want a simple thing, I want to use ACLs which are robust enough to be really cross-platform compatible and widely supported so I know I they will be supported even in 5-10 years. Ondrej -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendhalver at gmail.com Wed Oct 31 01:34:38 2012 From: rendhalver at gmail.com (Peter Brown) Date: Wed, 31 Oct 2012 11:34:38 +1000 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix Message-ID: Hi everyone, I have been trying to work out how to achieve this. I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix and dovecot on my new mail server authenticating against Freeipa. One last thing I would love to do it pull down the virtual users and aliases for the domains my mailserver will be serving from freeipa. Is this possible? Is this all automatic due to sssd looking up the user details in the ds? Does it do the same for domains and email aliases or will I need extra lookups to achieve this. Thanks in advance. Pete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Wed Oct 31 12:47:21 2012 From: simo at redhat.com (Simo Sorce) Date: Wed, 31 Oct 2012 08:47:21 -0400 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: <1351687641.2702.129.camel@willson.li.ssimo.org> On Wed, 2012-10-31 at 11:34 +1000, Peter Brown wrote: > Hi everyone, > > > I have been trying to work out how to achieve this. > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix > and dovecot on my new mail server authenticating against Freeipa. > One last thing I would love to do it pull down the virtual users and > aliases for the domains my mailserver will be serving from freeipa. > Is this possible? > Is this all automatic due to sssd looking up the user details in the > ds? > Does it do the same for domains and email aliases or will I need extra > lookups to achieve this. A loong time ago I sue the excellent support in postfix to route mail based on data in ldap, however I have no idea how's dovecot support for that. FreeIPA will create a single domain for you atm, but you can indeed associate any email address to a user, however sssd does not have any facility to resolve a user by email address, so unless you just care about the default domain (in which case you can lookup users via sssd just like you would against /etc/passwd) I think you'll have to configure your daemons to lookup data directly via ldap. Simo. -- Simo Sorce * Red Hat, Inc * New York From bret.wortman at damascusgrp.com Wed Oct 31 12:56:14 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 08:56:14 -0400 Subject: [Freeipa-users] User's choice: automount or autocreate? Message-ID: Has anyone set things up so that individual users have the option to automount a homedir or have one autocreated on each system they use for them? I have some users who prefer one way and others who prefer the other. Both have valid reasons and I'd rather not make an authoritarian decision for one over the other. 1. How could this be handled as a user option, set as the account is created or modified and open to adjustment later? 2. How might this be handled as a login option, allowing the user to select their automounted homedir or a local homedir? Anyone already set this up and have it working well? I'd hate to spend time re-inventing a wheel if there's already an excellent example in the wild.... Thanks! -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Oct 31 13:43:18 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 31 Oct 2012 09:43:18 -0400 Subject: [Freeipa-users] User's choice: automount or autocreate? In-Reply-To: References: Message-ID: <50912AF6.3070400@redhat.com> On Wed 31 Oct 2012 08:56:14 AM EDT, Bret Wortman wrote: > Has anyone set things up so that individual users have the option to > automount a homedir or have one autocreated on each system they use > for them? I have some users who prefer one way and others who prefer > the other. Both have valid reasons and I'd rather not make an > authoritarian decision for one over the other. > > 1. How could this be handled as a user option, set as the account is > created or modified and open to adjustment later? A feature could be added to SSSD to allow users to override the home directory location on individual clients. This feature would have to be subject to administrator approval in some way (to restrict where users could set their home directories and which users have this privilege). That requires some thought. Feel free to file an RFE at https://fedorahosted.org/sssd > 2. How might this be handled as a login option, allowing the user to > select their automounted homedir or a local homedir? > This just isn't going to happen. Period. The location of the user's home directory is an integral part of the user's identity on the system. It cannot vary at login time. All sessions of the logged-in user (as well as any application that calls getpwnam()) need to agree on this value or you will have problems. > Anyone already set this up and have it working well? I'd hate to spend > time re-inventing a wheel if there's already an excellent example in > the wild.... > As a general rule, it's usually better to just make the decision on a per-system basis than a per-user basis. I.e. everyone who logs on to certain infrastructure systems will always use the automount home directory, but on personal systems they can be configured to not use automount. From bret.wortman at damascusgrp.com Wed Oct 31 15:21:05 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 11:21:05 -0400 Subject: [Freeipa-users] User's choice: automount or autocreate? In-Reply-To: <50912AF6.3070400@redhat.com> References: <50912AF6.3070400@redhat.com> Message-ID: That's what I needed to know. We'll set a system-wide policy and be done with it. Thanks! On Wed, Oct 31, 2012 at 9:43 AM, Stephen Gallagher wrote: > On Wed 31 Oct 2012 08:56:14 AM EDT, Bret Wortman wrote: > >> Has anyone set things up so that individual users have the option to >> automount a homedir or have one autocreated on each system they use >> for them? I have some users who prefer one way and others who prefer >> the other. Both have valid reasons and I'd rather not make an >> authoritarian decision for one over the other. >> >> 1. How could this be handled as a user option, set as the account is >> >> created or modified and open to adjustment later? >> > > A feature could be added to SSSD to allow users to override the home > directory location on individual clients. This feature would have to be > subject to administrator approval in some way (to restrict where users > could set their home directories and which users have this privilege). That > requires some thought. Feel free to file an RFE at > https://fedorahosted.org/sssd > > 2. How might this be handled as a login option, allowing the user to >> >> select their automounted homedir or a local homedir? >> >> > This just isn't going to happen. Period. > > The location of the user's home directory is an integral part of the > user's identity on the system. It cannot vary at login time. All sessions > of the logged-in user (as well as any application that calls getpwnam()) > need to agree on this value or you will have problems. > > > Anyone already set this up and have it working well? I'd hate to spend >> time re-inventing a wheel if there's already an excellent example in >> the wild.... >> >> > > As a general rule, it's usually better to just make the decision on a > per-system basis than a per-user basis. I.e. everyone who logs on to > certain infrastructure systems will always use the automount home > directory, but on personal systems they can be configured to not use > automount. > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret.wortman at damascusgrp.com Wed Oct 31 15:53:15 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 11:53:15 -0400 Subject: [Freeipa-users] Sudo not working Message-ID: I'm pretty certain there's a painfully simple solution to this that I'm not seeing, but my current configuration isn't picking up the freeipa sudoer rule that I've set. /etc/nsswitch.conf specifies: sudoers: files ldap /etc/nslcd.conf contains: binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me bindpw password ssl start_tls tls_cacertfile /etc/ipa/ca.crt tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://fs1.wedgeofli.me sudoers_base ou=SUDOers,dc=wedgeofli,dc=me The sssd_DOMAIN.log file contains this when I try to sudo: (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users] (0x0400): Search users with filter: (&(objectclass=user)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1351698653)(!(lastLogin=*)))) (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users] (0x0400): No such entry (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_groups] (0x0400): Search groups with filter: (&(objectclass=group)(&(!(dataExpireTimestamp=0))(dataExpireTimestamp<=1351698653))) (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [cleanup_groups] (0x0100): Found 3 expired group entries! (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users] (0x0400): Search users with filter: (&(objectclass=user)(|(memberOf=name=nonexpiring,cn=groups,cn=wedgeofli.me ,cn=sysdb)(gidNumber=501))) (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users] (0x0400): Search users with filter: (&(objectclass=user)(|(memberOf=name=jtbays,cn=groups,cn=wedgeofli.me ,cn=sysdb)(gidNumber=1002))) (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [sysdb_search_users] (0x0400): Search users with filter: (&(objectclass=user)(|(memberOf=name=xmmgr,cn=groups,cn=wedgeofli.me ,cn=sysdb)(gidNumber=1015))) (Wed Oct 31 11:50:53 2012) [sssd[be[wedgeofli.me]]] [ldap_id_cleanup_set_timer] (0x0400): Scheduling next cleanup at 1351702253.2528 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_get_account_info] (0x0100): Got request for [3][1][name=bretw] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of ' fs1.wedgeofli.me' in files (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as 'resolving name' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as 'name resolved' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_resolve_server_done] (0x0200): Found address for server fs1.wedgeofli.me: [192.168.2.129] TTL 7200 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://fs1.wedgeofli.me' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/fs1.wedgeofli.me, WEDGEOFLI.ME, 86400) (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_resolve_server_done] (0x0200): Found address for server fs1.wedgeofli.me: [192.168.2.129] TTL 7200 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_WEDGEOFLI.ME], expired on [1351785056] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSSAPI, user: host/fs1.wedgeofli.me (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [child_sig_handler] (0x0100): child [17655] finished successfully. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'fs1.wedgeofli.me' as 'working' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as 'working' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_initgr_next_base] (0x0400): Searching for users with base [cn=accounts,dc=wedgeofli,dc=me] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(uid=bretw)(objectclass=posixAccount))][cn=accounts,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_save_user] (0x0400): Storing info for user bretw (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [uid=bretw,cn=users,cn=accounts,dc=wedgeofli,dc=me] using OpenLDAP deref (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(null)][uid=bretw,cn=users,cn=accounts,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler] (0x0100): Got request with the following data (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): domain: wedgeofli.me (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): user: bretw (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): service: sudo (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): tty: /dev/pts/2 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): ruser: bretw (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): rhost: (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): authtok type: 1 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): authtok size: 8 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): newauthtok size: 0 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): priv: 0 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): cli_pid: 17654 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [check_for_valid_tgt] (0x0080): TGT is valid. (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_resolve_server_done] (0x0200): Found address for server fs1.wedgeofli.me: [192.168.2.129] TTL 7200 (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [write_pipe_handler] (0x0400): All data has been sent! (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [read_pipe_handler] (0x0400): EOF received, client finished (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'fs1.wedgeofli.me' as 'working' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [set_server_common_status] (0x0100): Marking server 'fs1.wedgeofli.me' as 'working' (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Sending result [0][wedgeofli.me] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Sent result [0][wedgeofli.me] (Wed Oct 31 11:50:56 2012) [sssd[be[wedgeofli.me]]] [child_sig_handler] (0x0100): child [17656] finished successfully. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler] (0x0100): Got request with the following data (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): domain: wedgeofli.me (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): user: bretw (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): service: sudo (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): tty: /dev/pts/2 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): ruser: bretw (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): rhost: (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): authtok type: 0 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): authtok size: 0 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): newauthtok size: 0 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): priv: 0 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [pam_print_data] (0x0100): cli_pid: 17654 (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_access_send] (0x0400): Performing access check for user [bretw] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_account_expired_rhds] (0x0400): Performing RHDS access check for user [bretw] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipaHost)(fqdn=fs1.wedgeofli.me ))][cn=accounts,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [fqdn= fs1.wedgeofli.me,cn=computers,cn=accounts,dc=wedgeofli,dc=me] using OpenLDAP deref (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(null)][fqdn=fs1.wedgeofli.me,cn=computers,cn=accounts,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_parse_entry] (0x0400): Got deref control (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_x_deref_parse_entry] (0x0400): All deref results from a single control parsed (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [ipa_hostgroup_info_done] (0x0200): No host groups were dereferenced (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [ipa_hbac_service_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=wedgeofli,dc=me][2][(null)] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACService)][cn=hbac,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [ipa_hbac_servicegroup_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=wedgeofli,dc=me][2][(null)] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectClass=ipaHBACServiceGroup)][cn=hbac,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [ipa_hbac_rule_info_next] (0x0400): Sending request for next search base: [cn=hbac,dc=wedgeofli,dc=me][2][(null)] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=ipaHBACRule)(ipaenabledflag=TRUE)(|(hostCategory=all)(memberHost=fqdn= fs1.wedgeofli.me ,cn=computers,cn=accounts,dc=wedgeofli,dc=me)))][cn=hbac,dc=wedgeofli,dc=me]. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [sdap_get_generic_ext_done] (0x0400): Search result: Success(0), no errmsg set (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [hbac_get_category] (0x0200): Category is set to 'all'. (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [allow_all] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Sending result [0][wedgeofli.me] (Wed Oct 31 11:50:57 2012) [sssd[be[wedgeofli.me]]] [be_pam_handler_callback] (0x0100): Sent result [0][wedgeofli.me] I might be mis-reading this log, but I don't see anything going wrong during the search. -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgallagh at redhat.com Wed Oct 31 17:33:26 2012 From: sgallagh at redhat.com (Stephen Gallagher) Date: Wed, 31 Oct 2012 13:33:26 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: Message-ID: <509160E6.4070304@redhat.com> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: > I'm pretty certain there's a painfully simple solution to this that > I'm not seeing, but my current configuration isn't picking up the > freeipa sudoer rule that I've set. > > /etc/nsswitch.conf specifies: > sudoers: files ldap > > /etc/nslcd.conf contains: > > binddn uid=sudo,cn=sysaccounts,cn=etc,dc=wedgeofli,dc=me > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > > > The sssd_DOMAIN.log file contains this when I try to sudo: > The SSSD logs aren't showing anything wrong because they have nothing to do with the execution of the SUDO rules in this situation. All the SSSD is doing is verifying the authentication (when sudo prompts you for your password). The problem with the rule is most likely happening inside SUDO itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO to use its own internal LDAP driver to look up the rules. So you need to check sudo logs to see what's happening (probably you will need to enable debug logging in /etc/sudo.conf). Recent versions of SUDO (1.8.6 and later) have support for setting 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and later) for lookups (and caching) of sudo rules. From bret.wortman at damascusgrp.com Wed Oct 31 18:01:01 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 14:01:01 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> Message-ID: I had enabled debugging of sudo but am not clear on where that debugging is going. It's not stdout, and I'm not seeing anything in /var/log/messages. I'll try switching to SSS and see what that gets me. On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher wrote: > On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: > >> I'm pretty certain there's a painfully simple solution to this that >> I'm not seeing, but my current configuration isn't picking up the >> freeipa sudoer rule that I've set. >> >> /etc/nsswitch.conf specifies: >> sudoers: files ldap >> >> /etc/nslcd.conf contains: >> >> binddn uid=sudo,cn=sysaccounts,cn=**etc,dc=wedgeofli,dc=me >> bindpw password >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://fs1.wedgeofli.me >> >> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >> >> >> The sssd_DOMAIN.log file contains this when I try to sudo: >> >> > > > The SSSD logs aren't showing anything wrong because they have nothing to > do with the execution of the SUDO rules in this situation. All the SSSD is > doing is verifying the authentication (when sudo prompts you for your > password). > > The problem with the rule is most likely happening inside SUDO itself. > When you specify 'sudoers: files, ldap' in nsswitch.conf, it's telling SUDO > to use its own internal LDAP driver to look up the rules. So you need to > check sudo logs to see what's happening (probably you will need to enable > debug logging in /etc/sudo.conf). > > Recent versions of SUDO (1.8.6 and later) have support for setting > 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 and > later) for lookups (and caching) of sudo rules. > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 31 18:04:09 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 31 Oct 2012 14:04:09 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> Message-ID: <50916819.8070905@redhat.com> Bret Wortman wrote: > I had enabled debugging of sudo but am not clear on where that debugging > is going. It's not stdout, and I'm not seeing anything in /var/log/messages. > > I'll try switching to SSS and see what that gets me. What distro is this? If it is RHEL 6.3 then put the configuration into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are working on getting them fixed). rob > > > On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher > wrote: > > On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: > > I'm pretty certain there's a painfully simple solution to this that > I'm not seeing, but my current configuration isn't picking up the > freeipa sudoer rule that I've set. > > /etc/nsswitch.conf specifies: > sudoers: files ldap > > /etc/nslcd.conf contains: > > binddn uid=sudo,cn=sysaccounts,cn=__etc,dc=wedgeofli,dc=me > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > > > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > > > The sssd_DOMAIN.log file contains this when I try to sudo: > > > > > The SSSD logs aren't showing anything wrong because they have > nothing to do with the execution of the SUDO rules in this > situation. All the SSSD is doing is verifying the authentication > (when sudo prompts you for your password). > > The problem with the rule is most likely happening inside SUDO > itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, > it's telling SUDO to use its own internal LDAP driver to look up the > rules. So you need to check sudo logs to see what's happening > (probably you will need to enable debug logging in /etc/sudo.conf). > > Recent versions of SUDO (1.8.6 and later) have support for setting > 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 > and later) for lookups (and caching) of sudo rules. > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From bret.wortman at damascusgrp.com Wed Oct 31 18:10:47 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 14:10:47 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: <50916819.8070905@redhat.com> References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> Message-ID: F17. On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> I had enabled debugging of sudo but am not clear on where that debugging >> is going. It's not stdout, and I'm not seeing anything in >> /var/log/messages. >> >> I'll try switching to SSS and see what that gets me. >> > > What distro is this? If it is RHEL 6.3 then put the configuration into > /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are incorrect (we are > working on getting them fixed). > > rob > > >> >> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher > > wrote: >> >> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: >> >> I'm pretty certain there's a painfully simple solution to this >> that >> I'm not seeing, but my current configuration isn't picking up the >> freeipa sudoer rule that I've set. >> >> /etc/nsswitch.conf specifies: >> sudoers: files ldap >> >> /etc/nslcd.conf contains: >> >> binddn uid=sudo,cn=sysaccounts,cn=__**etc,dc=wedgeofli,dc=me >> >> bindpw password >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://fs1.wedgeofli.me >> >> >> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >> >> >> The sssd_DOMAIN.log file contains this when I try to sudo: >> >> >> >> >> The SSSD logs aren't showing anything wrong because they have >> nothing to do with the execution of the SUDO rules in this >> situation. All the SSSD is doing is verifying the authentication >> (when sudo prompts you for your password). >> >> The problem with the rule is most likely happening inside SUDO >> itself. When you specify 'sudoers: files, ldap' in nsswitch.conf, >> it's telling SUDO to use its own internal LDAP driver to look up the >> rules. So you need to check sudo logs to see what's happening >> (probably you will need to enable debug logging in /etc/sudo.conf). >> >> Recent versions of SUDO (1.8.6 and later) have support for setting >> 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD (1.9.0 >> and later) for lookups (and caching) of sudo rules. >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 31 18:20:00 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 31 Oct 2012 14:20:00 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> Message-ID: <50916BD0.2080608@redhat.com> Bret Wortman wrote: > F17. I think you want /etc/ldap.conf then. The easiest way to be sure the right file is being used is to add sudoers_debug 1 to the file. This will present a lot of extra output so you'll know the file is being read. rob > > On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > wrote: > > Bret Wortman wrote: > > I had enabled debugging of sudo but am not clear on where that > debugging > is going. It's not stdout, and I'm not seeing anything in > /var/log/messages. > > I'll try switching to SSS and see what that gets me. > > > What distro is this? If it is RHEL 6.3 then put the configuration > into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are > incorrect (we are working on getting them fixed). > > rob > > > > On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher > > >> wrote: > > On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: > > I'm pretty certain there's a painfully simple solution > to this that > I'm not seeing, but my current configuration isn't > picking up the > freeipa sudoer rule that I've set. > > /etc/nsswitch.conf specifies: > sudoers: files ldap > > /etc/nslcd.conf contains: > > binddn > uid=sudo,cn=sysaccounts,cn=____etc,dc=wedgeofli,dc=me > > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > > > > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > > > The sssd_DOMAIN.log file contains this when I try to sudo: > > > > > The SSSD logs aren't showing anything wrong because they have > nothing to do with the execution of the SUDO rules in this > situation. All the SSSD is doing is verifying the > authentication > (when sudo prompts you for your password). > > The problem with the rule is most likely happening inside SUDO > itself. When you specify 'sudoers: files, ldap' in > nsswitch.conf, > it's telling SUDO to use its own internal LDAP driver to > look up the > rules. So you need to check sudo logs to see what's happening > (probably you will need to enable debug logging in > /etc/sudo.conf). > > Recent versions of SUDO (1.8.6 and later) have support for > setting > 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD > (1.9.0 > and later) for lookups (and caching) of sudo rules. > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _________________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/__mailman/listinfo/freeipa-users > > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From bret.wortman at damascusgrp.com Wed Oct 31 18:35:02 2012 From: bret.wortman at damascusgrp.com (Bret Wortman) Date: Wed, 31 Oct 2012 14:35:02 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: <50916BD0.2080608@redhat.com> References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> Message-ID: [root at fs1 etc]# more /etc/ldap.conf sudoers_debug: 1 [root at fs1 etc]# ls -l /etc/ldap.conf -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf Where should I see the extra output? I've had this set since last Friday and I'm not seeing any difference. On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden wrote: > Bret Wortman wrote: > >> F17. >> > > I think you want /etc/ldap.conf then. The easiest way to be sure the right > file is being used is to add sudoers_debug 1 to the file. This will present > a lot of extra output so you'll know the file is being read. > > rob > > >> On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > > wrote: >> >> Bret Wortman wrote: >> >> I had enabled debugging of sudo but am not clear on where that >> debugging >> is going. It's not stdout, and I'm not seeing anything in >> /var/log/messages. >> >> I'll try switching to SSS and see what that gets me. >> >> >> What distro is this? If it is RHEL 6.3 then put the configuration >> into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are >> incorrect (we are working on getting them fixed). >> >> rob >> >> >> >> On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher >> >> >> wrote: >> >> On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman wrote: >> >> I'm pretty certain there's a painfully simple solution >> to this that >> I'm not seeing, but my current configuration isn't >> picking up the >> freeipa sudoer rule that I've set. >> >> /etc/nsswitch.conf specifies: >> sudoers: files ldap >> >> /etc/nslcd.conf contains: >> >> binddn >> uid=sudo,cn=sysaccounts,cn=___**_etc,dc=wedgeofli,dc=me >> >> >> bindpw password >> >> ssl start_tls >> tls_cacertfile /etc/ipa/ca.crt >> tls_checkpeer yes >> >> bind_timelimit 5 >> timelimit 15 >> >> uri ldap://fs1.wedgeofli.me >> >> >> >> sudoers_base ou=SUDOers,dc=wedgeofli,dc=me >> >> >> The sssd_DOMAIN.log file contains this when I try to >> sudo: >> >> >> >> >> The SSSD logs aren't showing anything wrong because they have >> nothing to do with the execution of the SUDO rules in this >> situation. All the SSSD is doing is verifying the >> authentication >> (when sudo prompts you for your password). >> >> The problem with the rule is most likely happening inside >> SUDO >> itself. When you specify 'sudoers: files, ldap' in >> nsswitch.conf, >> it's telling SUDO to use its own internal LDAP driver to >> look up the >> rules. So you need to check sudo logs to see what's happening >> (probably you will need to enable debug logging in >> /etc/sudo.conf). >> >> Recent versions of SUDO (1.8.6 and later) have support for >> setting >> 'sudoers: files, sss' in nsswitch.conf which DOES use SSSD >> (1.9.0 >> and later) for lookups (and caching) of sudo rules. >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**___________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> > >> https://www.redhat.com/__**mailman/listinfo/freeipa-users >> >> >> **> >> >> >> >> >> >> -- >> Bret Wortman >> The Damascus Group >> Fairfax, VA >> http://bretwortman.com/ >> http://twitter.com/BretWortman >> >> >> >> ______________________________**_________________ >> Freeipa-users mailing list >> Freeipa-users at redhat.com >> https://www.redhat.com/**mailman/listinfo/freeipa-users >> >> > -- Bret Wortman The Damascus Group Fairfax, VA http://bretwortman.com/ http://twitter.com/BretWortman -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Wed Oct 31 18:39:28 2012 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 31 Oct 2012 14:39:28 -0400 Subject: [Freeipa-users] Sudo not working In-Reply-To: References: <509160E6.4070304@redhat.com> <50916819.8070905@redhat.com> <50916BD0.2080608@redhat.com> Message-ID: <50917060.2080601@redhat.com> Bret Wortman wrote: > [root at fs1 etc]# more /etc/ldap.conf > sudoers_debug: 1 > [root at fs1 etc]# ls -l /etc/ldap.conf > -rw-r--r--. 1 root root 17 Oct 19 14:54 /etc/ldap.conf > > Where should I see the extra output? I've had this set since last Friday > and I'm not seeing any difference. Move the contents of /etc/nslcd.conf to this file and add ldap to sudoers in /etc/nsswitch.conf. rob > > On Wed, Oct 31, 2012 at 2:20 PM, Rob Crittenden > wrote: > > Bret Wortman wrote: > > F17. > > > I think you want /etc/ldap.conf then. The easiest way to be sure the > right file is being used is to add sudoers_debug 1 to the file. This > will present a lot of extra output so you'll know the file is being > read. > > rob > > > On Wed, Oct 31, 2012 at 2:04 PM, Rob Crittenden > > >> wrote: > > Bret Wortman wrote: > > I had enabled debugging of sudo but am not clear on > where that > debugging > is going. It's not stdout, and I'm not seeing anything in > /var/log/messages. > > I'll try switching to SSS and see what that gets me. > > > What distro is this? If it is RHEL 6.3 then put the > configuration > into /etc/sudo-ldap.conf instead of /etc/nslcd. The docs are > incorrect (we are working on getting them fixed). > > rob > > > > On Wed, Oct 31, 2012 at 1:33 PM, Stephen Gallagher > > > > >>> wrote: > > On Wed 31 Oct 2012 11:53:15 AM EDT, Bret Wortman > wrote: > > I'm pretty certain there's a painfully simple > solution > to this that > I'm not seeing, but my current configuration isn't > picking up the > freeipa sudoer rule that I've set. > > /etc/nsswitch.conf specifies: > sudoers: files ldap > > /etc/nslcd.conf contains: > > binddn > uid=sudo,cn=sysaccounts,cn=______etc,dc=wedgeofli,dc=me > > > bindpw password > > ssl start_tls > tls_cacertfile /etc/ipa/ca.crt > tls_checkpeer yes > > bind_timelimit 5 > timelimit 15 > > uri ldap://fs1.wedgeofli.me > > > > > sudoers_base ou=SUDOers,dc=wedgeofli,dc=me > > > The sssd_DOMAIN.log file contains this when I > try to sudo: > > > > > The SSSD logs aren't showing anything wrong > because they have > nothing to do with the execution of the SUDO rules > in this > situation. All the SSSD is doing is verifying the > authentication > (when sudo prompts you for your password). > > The problem with the rule is most likely happening > inside SUDO > itself. When you specify 'sudoers: files, ldap' in > nsswitch.conf, > it's telling SUDO to use its own internal LDAP > driver to > look up the > rules. So you need to check sudo logs to see > what's happening > (probably you will need to enable debug logging in > /etc/sudo.conf). > > Recent versions of SUDO (1.8.6 and later) have > support for > setting > 'sudoers: files, sss' in nsswitch.conf which DOES > use SSSD > (1.9.0 > and later) for lookups (and caching) of sudo rules. > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > ___________________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > > > https://www.redhat.com/____mailman/listinfo/freeipa-users > > > > __> > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _________________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/__mailman/listinfo/freeipa-users > > > > > > > -- > Bret Wortman > The Damascus Group > Fairfax, VA > http://bretwortman.com/ > http://twitter.com/BretWortman > > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users > From dpal at redhat.com Wed Oct 31 22:00:55 2012 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 31 Oct 2012 18:00:55 -0400 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: <50919F97.1060207@redhat.com> On 10/30/2012 09:34 PM, Peter Brown wrote: > Hi everyone, > > I have been trying to work out how to achieve this. > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix > and dovecot on my new mail server authenticating against Freeipa. > One last thing I would love to do it pull down the virtual users and > aliases for the domains my mailserver will be serving from freeipa. > Is this possible? > Is this all automatic due to sssd looking up the user details in the ds? > Does it do the same for domains and email aliases or will I need extra > lookups to achieve this. > > Thanks in advance. > Pete. > > > _______________________________________________ > Freeipa-users mailing list > Freeipa-users at redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-users I am not sure if anything on those pages is relevant to what you are trying to accomplish but they talk about FreeIPA and dovecot integration: http://www.freeipa.org/page/Dovecot_Integration http://www.freeipa.org/page/Dovecot_IMAPS_Integration_with_FreeIPA_using_Single_Sign_On If not the author of the pages - Dale might have more experience with the similar environment and might have tried what you are looking for. HTH -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. ------------------------------- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbingram at gmail.com Wed Oct 31 22:20:50 2012 From: sbingram at gmail.com (Stephen Ingram) Date: Wed, 31 Oct 2012 15:20:50 -0700 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: On Tue, Oct 30, 2012 at 6:34 PM, Peter Brown wrote: > Hi everyone, > > I have been trying to work out how to achieve this. > I have freeipa 3.0.0 setup on a Fedora 18 server and I have postfix and > dovecot on my new mail server authenticating against Freeipa. > One last thing I would love to do it pull down the virtual users and aliases > for the domains my mailserver will be serving from freeipa. > Is this possible? > Is this all automatic due to sssd looking up the user details in the ds? > Does it do the same for domains and email aliases or will I need extra > lookups to achieve this. I've recently built an entire mail system around FreeIPA and it works great. There are two parts to be concerned with: 1. Authentication - With Postfix, this is handled by saslauthd which can authenticate against Kerberos (using or not using sssd). I used Cyrus-IMAP for the mailstore which also uses saslauthd. Doveccot has it's own sasl built in which can authenticate against Kerberos or LDAP, thus it should work with IPA. 2. Configuration - With Postfix, you can set all different areas (e.g. virtual, aliases, etc.) to use LDAP lookup of configuration information. You are typically searching for the email address (mail attribute in IPA) and your search will generally return the userid (uid attribute) of where the mail is to be stored. I don't believe that Dovecot or Cyrus-IMAP have any way of maintaining any configuration in LDAP so you generally have to setup mailboxes and authorization information by hand using their tools. Steve