<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> Yes, it's the enforced user permissions for NFS shares, versus host-based access controls and matching UIDs/GIDs, that I'm after, especially as I have IPA providing the central user LDAP store. I admit I don't really understand how it all hangs together in terms of requiring a kerberos ticket, but maybe someone can enlighten me or point me to relavant info for IPA. Should a user execute a kinit to get a new ticket before using any services or are their popular approaches to automating this? Both the NFS server and client can getent the admin user so that aspect is fine, but as Bryce states, I'm stuck not even able to mount the share, let alone have any permission issues using it. I have read the link mention by Bryce: <pre wrap=""><a class="moz-txt-link-freetext" href="http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html">http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html</a></pre> At the time I thought the OP had the issue because the keytabs were being created by someone else (Windows AD admins), whereas I'm creating mine with the default options in IPA. It (and other posts) did originally lead me down enabling weak encryption and specifying a specific DES scheme to use and only having this single entry in the keytab for both the host and nfs principals (on both the NFS server and client). Though this made no difference. I've just looked at the ipa man page and can't see how (or if I need) to set either "/crypto ALL" or NO_AUTH_DATA_REQUIRED ipa help service-add Purpose: Add a new IPA new service. Usage: ipa [global-options] service-add PRINCIPAL [options] Positional arguments: PRINCIPAL Service principal Options: -h, --help show this help message and exit --certificate=BYTES Base-64 encoded server certificate --pac-type=['MS-PAC', 'PAD', 'NONE'] Override default list of supported PAC types. Use 'NONE' to disable PAC support for this service --setattr=STR Set an attribute to a name/value pair. Format is attr=value. For multi-valued attributes, the command replaces the values already present. --addattr=STR Add an attribute/value pair. Format is attr=value. The attribute must be part of the schema. --force force principal name even if not in DNS --all Retrieve and print all attributes from the server. Affects command output. --raw Print entries as stored on the server. Only affects output format. Likewise, I looked for attributes against a test user and could find nothing about setting preauth or the NO_AUTH_DATA_REQUIRED flag above. Maybe I'm looking in the wrong place/way? ipa user-show --all User login: joebloggsuser dn: uid=joebloggsuser,cn=users,cn=accounts,dc=example,dc=local User login: joebloggsuser First name: Joe Last name: Bloggs Full name: Joe Bloggs Display name: Joe Bloggs Initials: JB Home directory: /home/joebloggsuser GECOS field: Joe Bloggs Login shell: /bin/bash Kerberos principal: <a class="moz-txt-link-abbreviated" href="mailto:joebloggsuser@EXAMPLE.LOCAL">joebloggsuser@EXAMPLE.LOCAL</a> Email address: <a class="moz-txt-link-abbreviated" href="mailto:joebloggs@example.local">joebloggs@example.local</a> UID: 94600001 GID: 94600001 Account disabled: False SSH public key: ssh-rsa <BLAH BLAH...> <a class="moz-txt-link-abbreviated" href="mailto:joebloggsuser@example.local">joebloggsuser@example.local</a> Password: True Member of groups: ipausers, super Indirect Member of group: admins, editors, trust admins, exampleusers, advocacy, managers Kerberos keys available: True SSH public key fingerprint: <BLAH BLAH...> <a class="moz-txt-link-abbreviated" href="mailto:joebloggsuser@example.local">joebloggsuser@example.local</a> (ssh-rsa) ipauniqueid: 511c7d14-91d0-11e3-b10e-001a4ab13d9f krbextradata: BBBoyf9Sa2FkzxluZEBCRFMuTE9EQUvA krblastfailedauth: 20140215200740Z krblastpwdchange: 20140215200912Z krblastsuccessfulauth: 20140217003353Z krbloginfailedcount: 0 krbpasswordexpiration: 20150215200912Z krbpwdpolicyreference: cn=super,cn=EXAMPLE.LOCAL,cn=kerberos,dc=example,dc=local krbticketflags: 128 mepmanagedentry: cn=joebloggsuser,cn=groups,cn=accounts,dc=example,dc=local objectclass: top, person, organizationalperson, inetorgperson, inetuser, posixaccount, krbprincipalaux, krbticketpolicyaux, ipaobject, ipasshuser, ipaSshGroupOfPubKeys, mepOriginEntry Any ideas how I can move this forward, as kerberized NFS would definitely be preferable and I thought this would be easy with IPA? Thanks, Paul <div class="moz-cite-prefix">On 17/02/2014 14:26, <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users-request@redhat.com">freeipa-users-request@redhat.com</a> wrote: </div> <blockquote cite="mid:mailman.15454.1392647163.18909.freeipa-users@redhat.com" type="cite"> <pre wrap="">Send Freeipa-users mailing list submissions to <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> To subscribe or unsubscribe via the World Wide Web, visit <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> or, via email, send a message with subject or body 'help' to <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users-request@redhat.com">freeipa-users-request@redhat.com</a> You can reach the person managing the list at <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users-owner@redhat.com">freeipa-users-owner@redhat.com</a> When replying, please edit your Subject line so it is more specific than "Re: Contents of Freeipa-users digest..." Today's Topics: 1. Re: Kerberized NFS Mount Issues (Nordgren, Bryce L -FS) 2. Re: Issues creating trust with AD. (Sumit Bose) 3. Re: Sudo denied on first attempt, allowed on second attempt (Pavel B?ezina) 4. Re: authentication against compat (Jakub Hrozek) 5. Re: Setting up sudo (Jakub Hrozek) 6. Re: Setting up sudo (Andrew Holway) ---------------------------------------------------------------------- Message: 1 Date: Sun, 16 Feb 2014 23:10:58 +0000 From: "Nordgren, Bryce L -FS" <a class="moz-txt-link-rfc2396E" href="mailto:bnordgren@fs.fed.us"><bnordgren@fs.fed.us></a> To: <a class="moz-txt-link-rfc2396E" href="mailto:regpm@mccleary.me.uk">"regpm@mccleary.me.uk"</a> <a class="moz-txt-link-rfc2396E" href="mailto:regpm@mccleary.me.uk"><regpm@mccleary.me.uk></a>, <a class="moz-txt-link-rfc2396E" href="mailto:freeipa-users@redhat.com">"freeipa-users@redhat.com"</a> <a class="moz-txt-link-rfc2396E" href="mailto:freeipa-users@redhat.com"><freeipa-users@redhat.com></a> Subject: Re: [Freeipa-users] Kerberized NFS Mount Issues Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:82E7C9A01FD0764CACDD35D10F5DFB6E68E086@001FSN2MPN1-045.001f.mgd2.msft.net"><82E7C9A01FD0764CACDD35D10F5DFB6E68E086@001FSN2MPN1-045.001f.mgd2.msft.net></a> Content-Type: text/plain; charset="iso-8859-1" </pre> <blockquote type="cite"> <pre wrap="">You raise a good point regarding kinit - do I have to be kinit'ed in as anybody before trying to mount the share? I thought as the host and service principals are in the /etc/krb5.keytab I didn't need to specifically authenticate against the IPA server? - I might be showing a fundamental lack of knowledge on how this all works, so would be good if someone could confirm or clarify this. </pre> </blockquote> <pre wrap=""> The big feature of NFSv4 w/krb security is per-user authentication/authorization. NFSv4 with sec=sys (and all NFS <4) use host-based authorization. I'm pretty sure you should be able to mount the NFS export without 'kinit'ing, but I'm also pretty sure it should look empty (or even give you "permission denied" until you kinit to someone authorized to access it. I see you "kinit"ed to <a class="moz-txt-link-rfc2396E" href="mailto:admin@EXAMPLE.LOCAL">"admin@EXAMPLE.LOCAL"</a>. If I'm not mistaken, this means that when you create files, NFS communicates the owner as <a class="moz-txt-link-rfc2396E" href="mailto:admin@example.local">"admin@example.local"</a>. Your idmappers are probably trying to translate this to a local account called "admin" whenever evaluating permissions. If nfs-client and nfs-server can both "getent passwd admin" successfully, then you're probably OK. Otherwise, sssd may need some work... But that shouldn't interfere with just mounting the share. (I just checked on my little test setup.) My little test setup doesn't involve IPA, it's just a couple of fedora20 VMs with mit krb5 and an nfs server. I did google this: <a class="moz-txt-link-freetext" href="http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html">http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html</a> Note the part about the campus windows AD admins setting the NO_AUTH_DATA_REQUIRED flag for the machine accounts in AD. Is preauth turned off for your nfs/nfs-client.... and nfs/nfs-server... principals? I fear I'm ignorant of how this is done in IPA. Bryce This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately. ------------------------------ Message: 2 Date: Mon, 17 Feb 2014 09:34:33 +0100 From: Sumit Bose <a class="moz-txt-link-rfc2396E" href="mailto:sbose@redhat.com"><sbose@redhat.com></a> To: Genadi Postrilko <a class="moz-txt-link-rfc2396E" href="mailto:genadipost@gmail.com"><genadipost@gmail.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> Subject: Re: [Freeipa-users] Issues creating trust with AD. Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:20140217083433.GI15419@localhost.localdomain"><20140217083433.GI15419@localhost.localdomain></a> Content-Type: text/plain; charset=us-ascii On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote: </pre> <blockquote type="cite"> <pre wrap="">I have seen threads where opened on trust issues: "AD - Freeipa trust confusion" "Cross domain trust" "Cannot loging via SSH with AD user TO IPA Domain" - which I opened. It looks like after creation of trust, TGT ticket can be issued from AD, but "su" and "ssh" do not allow a log in with AD user. I'm not sure if a conclusion has been reached on this subject. I gave it a try again and attempted to create a trust with IPA as a DNS subdomain of AD. I followed : <a class="moz-txt-link-freetext" href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html</a> AD domain: ADEXAMPLE.COM IPA subdoamin: LINUX.ADEXAMPLE.COM When i finished the necessary steps i attempted to retrieve a TGT from AD (while logged in to IPA server): [root@ipaserver1 sbin]# kinit <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a> Password for <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a>: [root@ipaserver1 sbin]# klist Ticket cache: <a class="moz-txt-link-freetext" href="FILE:/tmp/krb5cc_0">FILE:/tmp/krb5cc_0</a> Default principal: <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a> Valid starting Expires Service principal 02/14/14 07:50:21 02/14/14 17:50:20 <a class="moz-txt-link-abbreviated" href="mailto:krbtgt/ADEXAMPLE.COM@ADEXAMPLE.COM">krbtgt/ADEXAMPLE.COM@ADEXAMPLE.COM</a> renew until 02/15/14 07:50:21 But logging in by "ssh" and "su" ended in failure: login as: <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a> <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADDC.COM@192.168.227.201">Administrator@ADDC.COM@192.168.227.201</a>'s password: Access denied After reading <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini">http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini</a> did the following on the AD server: Administrative Tools -> Active Directory Domains and Trust -> adexample.com(right click) -> Properties -> Trust -> Domain Trusted by this domain (outgoing trust) -> Properties -> General -> Validate *After doing this i was able to login via "ssh" and "su" with "Administrator" **user :* login as: <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a> <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM@192.168.227.201">Administrator@ADEXAMPLE.COM@192.168.227.201</a>'s password: Last login: Wed Feb 12 14:39:49 2014 from 192.168.227.1 Could not chdir to home directory /home/adexample.com/administrator: No such file or directory /usr/bin/xauth: error in locking authority file /home/ adexample.com/administrator/.Xauthority -sh-4.1$ *But still not able to login with other AD accounts:* [root@ipaserver1 sbin]# su <a class="moz-txt-link-abbreviated" href="mailto:Genadi@ADEXAMPLE.COM">Genadi@ADEXAMPLE.COM</a> su: user <a class="moz-txt-link-abbreviated" href="mailto:Genadi@ADEXAMPLE.COM">Genadi@ADEXAMPLE.COM</a> does not exist After reading the other threads, ill try and provide as much information as i can: *wbinfo -u does not return values.* [root@ipaserver1 sbin]# wbinfo -u [root@ipaserver1 sbin]# *wbinfo -u output:* [root@ipaserver1 sbin]# wbinfo -g admins editors default smb group ad_users *wbinfo --online-status shows ADEXAMPLE is offline* [root@ipaserver1 ~]# wbinfo --online-status BUILTIN : online LINUX : online ADEXAMPLE : offline *getent for Administrator does return value.* [root@ipaserver1 sbin]# getent passwd <a class="moz-txt-link-abbreviated" href="mailto:Administrator@ADEXAMPLE.COM">Administrator@ADEXAMPLE.COM</a> <a class="moz-txt-link-abbreviated" href="mailto:administrator@adexample.com:*:699000500:699000500::/home/">administrator@adexample.com:*:699000500:699000500::/home/</a> adexample.com/administrator: *getent for other AD users does not return value.* [root@ipaserver1 sbin]# getent passwd <a class="moz-txt-link-abbreviated" href="mailto:Genadi@ADEXAMPLE.COM">Genadi@ADEXAMPLE.COM</a> [root@ipaserver1 sbin]# *System info/configurations:* [root@ipaserver1 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.2 Beta (Santiago) [root@ipaserver1 sbin]# rpm -qa | grep ipa ipa-python-3.0.0-37.el6.x86_64 ipa-client-3.0.0-37.el6.x86_64 libipa_hbac-python-1.9.2-129.el6.x86_64 ipa-pki-common-theme-9.0.3-7.el6.noarch ipa-server-trust-ad-3.0.0-37.el6.x86_64 libipa_hbac-1.9.2-129.el6.x86_64 ipa-admintools-3.0.0-37.el6.x86_64 ipa-server-selinux-3.0.0-37.el6.x86_64 ipa-pki-ca-theme-9.0.3-7.el6.noarch ipa-server-3.0.0-37.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch [root@ipaserver1 ~]# rpm -qa | grep sssd sssd-1.9.2-129.el6.x86_64 sssd-client-1.9.2-129.el6.x86_64 [root@ipaserver1 sbin]# rpm -qa | grep samb samba4-common-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-clients-4.0.0-60.el6_5.rc4.x86_64 samba4-libs-4.0.0-60.el6_5.rc4.x86_64 samba4-python-4.0.0-60.el6_5.rc4.x86_64 samba4-4.0.0-60.el6_5.rc4.x86_64 samba4-client-4.0.0-60.el6_5.rc4.x86_64 samba4-winbind-4.0.0-60.el6_5.rc4.x86_64 </pre> </blockquote> <pre wrap=""> Thank you very much for the detailed report. Looks like you are hit by the 'NT_STATUS_INVALID_PARAMETER_MIX' issue (see log.wb-ADEXAMPLE). We are currently investigating this issue. I you would like to help it would be nice if you can try to downgrade the samba4 packages to the -58 release and see if this works any better for you. Currently I'll try tor reproduce this issue locally and will give you an update as soon as I find anything which might help to get around this issue. bye, Sumit </pre> <blockquote type="cite"> <pre wrap=""> *SSSD* [root@ipaserver1 ~]# cat /etc/sssd/sssd.conf [domain/linux.adexample.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = linux.adexample.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipaserver1.linux.adexample.com chpass_provider = ipa ipa_server = ipaserver1.linux.adexample.com ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa debug_level = 6 [sssd] services = nss, pam, ssh, pac config_file_version = 2 domains = linux.adexample.com debug_level = 6 [nss] debug_level = 6 [pam] debug_level = 6 [sudo] debug_level = 6 [autofs] debug_level = 6 [ssh] debug_level = 6 [pac] debug_level = 6 *KRB5* [root@ipaserver1 ~]# cat /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = <a class="moz-txt-link-freetext" href="FILE:/var/log/krb5libs.log">FILE:/var/log/krb5libs.log</a> kdc = <a class="moz-txt-link-freetext" href="FILE:/var/log/krb5kdc.log">FILE:/var/log/krb5kdc.log</a> admin_server = <a class="moz-txt-link-freetext" href="FILE:/var/log/kadmind.log">FILE:/var/log/kadmind.log</a> [libdefaults] default_realm = LINUX.ADEXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes [realms] LINUX.ADEXAMPLE.COM = { kdc = ipaserver1.linux.adexample.com:88 master_kdc = ipaserver1.linux.adexample.com:88 admin_server = ipaserver1.linux.adexample.com:749 default_domain = linux.adexample.com pkinit_anchors = <a class="moz-txt-link-freetext" href="FILE:/etc/ipa/ca.crt">FILE:/etc/ipa/ca.crt</a> auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@ <a class="moz-txt-link-abbreviated" href="mailto:ADEXAMPLE.COM/@adexample.com/">ADEXAMPLE.COM/@adexample.com/</a> auth_to_local = DEFAULT } [domain_realm] .linux.adexample.com = LINUX.ADEXAMPLE.COM linux.adexample.com = LINUX.ADEXAMPLE.COM [dbmodules] LINUX.ADEXAMPLE.COM = { db_library = ipadb.so } I have increased the debug level of the IPA components. Here are the logs (*krb5_child.log, **ldap_child.log, **log.smbd, **log.wb-ADEXAMPLE, **log.wb-LINUX, **log.winbindd, **log.winbindd-dc-connect, log.winbindd-idmap*, *sssd.log*, *sssd_linux.adexample.com.log*,*sssd_nss.log, **sssd_pac.log*, *sssd_pam.log, * *sssd_ssh.log, /var/log/secure):<a class="moz-txt-link-freetext" href="https://gist.github.com/anonymous/9006532">https://gist.github.com/anonymous/9006532</a> <a class="moz-txt-link-rfc2396E" href="https://gist.github.com/anonymous/9006532"><https://gist.github.com/anonymous/9006532></a>* Any insights on why only Administrator is recognized by the Trust? And why extra step on AD was needed? </pre> </blockquote> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">_______________________________________________ Freeipa-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> </pre> </blockquote> <pre wrap=""> ------------------------------ Message: 3 Date: Mon, 17 Feb 2014 09:46:53 +0100 From: Pavel B?ezina <a class="moz-txt-link-rfc2396E" href="mailto:pbrezina@redhat.com"><pbrezina@redhat.com></a> To: Steve Dainard <a class="moz-txt-link-rfc2396E" href="mailto:sdainard@miovision.com"><sdainard@miovision.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> Subject: Re: [Freeipa-users] Sudo denied on first attempt, allowed on second attempt Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:5301CC7D.6050903@redhat.com"><5301CC7D.6050903@redhat.com></a> Content-Type: text/plain; charset=UTF-8; format=flowed On 02/16/2014 01:19 AM, Steve Dainard wrote: </pre> <blockquote type="cite"> <pre wrap="">Just experienced the same issue on Fedora 20: [<a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp@fed20">sdainard-admin@miovision.corp@fed20</a> ~]$ sudo systemctl stop firewalld [sudo] password for <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a>: <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a> is not allowed to run sudo on fed20. This incident will be reported. [<a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp@fed20">sdainard-admin@miovision.corp@fed20</a> ~]$ sudo systemctl stop firewalld [sudo] password for <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a>: [<a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp@fed20">sdainard-admin@miovision.corp@fed20</a> ~]$ Sat Feb 15 19:10:30 2014 is the 2nd attempt in the logs (attached). /var/log/messages: Feb 15 19:10:31 fed20 systemd: Stopping firewalld - dynamic firewall daemon... Feb 15 19:10:31 fed20 systemd: Stopped firewalld - dynamic firewall daemon. *Steve Dainard * IT Infrastructure Manager Miovision <a class="moz-txt-link-rfc2396E" href="http://miovision.com/"><http://miovision.com/></a> | /Rethink Traffic/ *Blog <a class="moz-txt-link-rfc2396E" href="http://miovision.com/blog"><http://miovision.com/blog></a> | **LinkedIn <a class="moz-txt-link-rfc2396E" href="https://www.linkedin.com/company/miovision-technologies"><https://www.linkedin.com/company/miovision-technologies></a> | Twitter <a class="moz-txt-link-rfc2396E" href="https://twitter.com/miovision"><https://twitter.com/miovision></a> | Facebook <a class="moz-txt-link-rfc2396E" href="https://www.facebook.com/miovision"><https://www.facebook.com/miovision></a>* ------------------------------------------------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. On Fri, Feb 14, 2014 at 4:33 PM, Steve Dainard <<a class="moz-txt-link-abbreviated" href="mailto:sdainard@miovision.com">sdainard@miovision.com</a> <a class="moz-txt-link-rfc2396E" href="mailto:sdainard@miovision.com"><mailto:sdainard@miovision.com></a>> wrote: On a Ubuntu 13.10 client after configuring sssd to provide sudo service I left the client idle for a few hours. On returning, I unlocked the screensaver and did the following: <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp@ubu1310:~$">sdainard-admin@miovision.corp@ubu1310:~$</a> sudo su [sudo] password for <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a>: <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a> is not allowed to run sudo on ubu1310. This incident will be reported. <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp@ubu1310:~$">sdainard-admin@miovision.corp@ubu1310:~$</a> sudo su [sudo] password for <a class="moz-txt-link-abbreviated" href="mailto:sdainard-admin@miovision.corp">sdainard-admin@miovision.corp</a>: <a class="moz-txt-link-abbreviated" href="mailto:root@ubu1310:/home/miovision.corp/sdainard-admin#">root@ubu1310:/home/miovision.corp/sdainard-admin#</a> I haven't experienced this on a Fedora 20 or EL client so I'm guessing this is something specific to Ubuntu. I've attached the client sssd log if anyone can point me in the right direction. Thanks, *Steve Dainard * IT Infrastructure Manager Miovision <a class="moz-txt-link-rfc2396E" href="http://miovision.com/"><http://miovision.com/></a> | /Rethink Traffic/ *Blog <a class="moz-txt-link-rfc2396E" href="http://miovision.com/blog"><http://miovision.com/blog></a> | **LinkedIn <a class="moz-txt-link-rfc2396E" href="https://www.linkedin.com/company/miovision-technologies"><https://www.linkedin.com/company/miovision-technologies></a> | Twitter <a class="moz-txt-link-rfc2396E" href="https://twitter.com/miovision"><https://twitter.com/miovision></a> | Facebook <a class="moz-txt-link-rfc2396E" href="https://www.facebook.com/miovision"><https://www.facebook.com/miovision></a>* ------------------------------------------------------------------------ Miovision Technologies Inc. | 148 Manitou Drive, Suite 101, Kitchener, ON, Canada | N2C 1L3 This e-mail may contain information that is privileged or confidential. If you are not the intended recipient, please delete the e-mail and any attachments and notify us immediately. </pre> </blockquote> <pre wrap=""> Hi, provided logs did not reveal anything bad. Can you also attach sssd_sudo.log, sssd_nss.log and sssd.conf please? Also what sssd and sudo version do you run? Is this always reproducible or it happens only sporadically? Thanks. ------------------------------ Message: 4 Date: Mon, 17 Feb 2014 15:03:00 +0100 From: Jakub Hrozek <a class="moz-txt-link-rfc2396E" href="mailto:jhrozek@redhat.com"><jhrozek@redhat.com></a> To: Alexander Bokovoy <a class="moz-txt-link-rfc2396E" href="mailto:abokovoy@redhat.com"><abokovoy@redhat.com></a> Cc: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> Subject: Re: [Freeipa-users] authentication against compat Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:20140217140300.GE7979@hendrix.brq.redhat.com"><20140217140300.GE7979@hendrix.brq.redhat.com></a> Content-Type: text/plain; charset=us-ascii On Fri, Feb 14, 2014 at 09:36:33AM +0200, Alexander Bokovoy wrote: </pre> <blockquote type="cite"> <pre wrap="">On Thu, 13 Feb 2014, Steve Dainard wrote: </pre> <blockquote type="cite"> <pre wrap="">I don't think this is an issue of bugs or documentation, more of design. Perhaps there's someplace other than a users list this belongs in but: If IPA is a centrally managed identity and access control system, should these configurations not be passed to clients, rather than every client needing configuration changes post join? Obviously I can automate config changes, but why would I want to? I don't think sudoers priv is a fringe case, its pretty much THE case for access/admin control. I cringe to compare to a Windows domain, but I don't have to manually tell a domain client that it should respect the rules I set on a domain controller, I joined it to the domain for this reason. </pre> </blockquote> <pre wrap="">When majority of expected features are already implemented, it is easy to fall into assumption that everything has to be complete from start. That's understandable but we are dealing with a living and evolving project where a feature addition often means integrating across multiple actual free software projects, all with their own priorities and schedules, step by step, or things will never happen. SUDO integration is not an exception here. First we needed to expand SUDO's support for external plugins. When SUDO data was placed in LDAP, it appeared that existing schema isn't really optimal, so FreeIPA schema was designed better (but incompatible with existing one from SUDO LDAP), but required a compatibility part to work with existing SUDO LDAP plugin. Next, we implemented SUDO provider in SSSD for the existing SUDO LDAP schema as it gave SSSD wider coverage of SUDO support. Now we implemented support for native FreeIPA schema. The next step is to integrate configuration of it in ipa-client-install so that clients will get set up properly if there are SUDO rules configured on the server or ipa-client-install was actually given a bless from the admin (via CLI option or answering a question). It takes time and effort. Unsurprisingly, this is a relatively minor feature in the grand picture because we have dozens of such features all asking for attention and time, and our development teams are not expanding infinitely regardless how we all wished. :) Any help is welcome! </pre> </blockquote> <pre wrap=""> By the way the native sudo backend is being worked on actively by an external contributor in the form of a thesis. We expect to have it implemented by May. ------------------------------ Message: 5 Date: Mon, 17 Feb 2014 15:08:10 +0100 From: Jakub Hrozek <a class="moz-txt-link-rfc2396E" href="mailto:jhrozek@redhat.com"><jhrozek@redhat.com></a> To: <a class="moz-txt-link-abbreviated" href="mailto:freeipa-users@redhat.com">freeipa-users@redhat.com</a> Subject: Re: [Freeipa-users] Setting up sudo Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:20140217140810.GG7979@hendrix.brq.redhat.com"><20140217140810.GG7979@hendrix.brq.redhat.com></a> Content-Type: text/plain; charset=us-ascii On Thu, Feb 13, 2014 at 06:30:37PM -0500, Dmitri Pal wrote: </pre> <blockquote type="cite"> <pre wrap="">On 02/13/2014 06:23 PM, Todd Maugh wrote: </pre> <blockquote type="cite"> <pre wrap="">and If I am configuring the sud-ldap.conf what should it look like does any one have an example? </pre> </blockquote> <pre wrap=""> You have two options. Sudo can be integrated with SSSD or not. If you want SUDO to be integrated then this should help: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf">http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf</a> </pre> </blockquote> <pre wrap=""> Also man sssd-sudo should have some examples. ------------------------------ Message: 6 Date: Mon, 17 Feb 2014 14:25:57 +0000 From: Andrew Holway <a class="moz-txt-link-rfc2396E" href="mailto:andrew.holway@gmail.com"><andrew.holway@gmail.com></a> To: Todd Maugh <a class="moz-txt-link-rfc2396E" href="mailto:tmaugh@boingo.com"><tmaugh@boingo.com></a> Cc: <a class="moz-txt-link-rfc2396E" href="mailto:freeipa-users@redhat.com">"freeipa-users@redhat.com"</a> <a class="moz-txt-link-rfc2396E" href="mailto:freeipa-users@redhat.com"><freeipa-users@redhat.com></a> Subject: Re: [Freeipa-users] Setting up sudo Message-ID: <a class="moz-txt-link-rfc2396E" href="mailto:CAEiui-s3LajmkiXF_7=0M_BvddHFoZg-51RR5jjyt303bi2Zmw@mail.gmail.com"><CAEiui-s3LajmkiXF_7=0M_BvddHFoZg-51RR5jjyt303bi2Zmw@mail.gmail.com></a> Content-Type: text/plain; charset=ISO-8859-1 It actually took me a long time to find this information. It is poorly documented but this mailing list post works. :) <a class="moz-txt-link-freetext" href="https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html">https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html</a> On 13 February 2014 23:17, Todd Maugh <a class="moz-txt-link-rfc2396E" href="mailto:tmaugh@boingo.com"><tmaugh@boingo.com></a> wrote: </pre> <blockquote type="cite"> <pre wrap="">the documentation is kinda vague on some parts from the documentation: Because the sudo information is not available anonymously over LDAP by default, Identity Management defines a default sudo user, uid=sudo,cn=sysaccounts,cn=etc,$SUFFIX, which can be set in the LDAP/sudo configuration file, /etc/sud-ldap.conf. so is this user supposed to already pre defined. or do I need to create the user, and then modify them thanks -Todd _______________________________________________ Freeipa-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> </pre> </blockquote> <pre wrap=""> ------------------------------ _______________________________________________ Freeipa-users mailing list <a class="moz-txt-link-abbreviated" href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a> <a class="moz-txt-link-freetext" href="https://www.redhat.com/mailman/listinfo/freeipa-users">https://www.redhat.com/mailman/listinfo/freeipa-users</a> End of Freeipa-users Digest, Vol 67, Issue 88 ********************************************* </pre> </blockquote> </body> </html>