[Freeipa-users] Freeipa-users Digest, Vol 67, Issue 88
regpm at mccleary.me.uk
regpm at mccleary.me.uk
Mon Feb 17 19:30:05 UTC 2014
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:
http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html
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: joebloggsuser at EXAMPLE.LOCAL
Email address: joebloggs at example.local
UID: 94600001
GID: 94600001
Account disabled: False
SSH public key: ssh-rsa
<BLAH BLAH...>
joebloggsuser at example.local
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...>
joebloggsuser at example.local (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
On 17/02/2014 14:26, freeipa-users-request at redhat.com wrote:
> Send Freeipa-users mailing list submissions to
> freeipa-users at redhat.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.redhat.com/mailman/listinfo/freeipa-users
> or, via email, send a message with subject or body 'help' to
> freeipa-users-request at redhat.com
>
> You can reach the person managing the list at
> freeipa-users-owner at redhat.com
>
> 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" <bnordgren at fs.fed.us>
> To: "regpm at mccleary.me.uk" <regpm at mccleary.me.uk>,
> "freeipa-users at redhat.com" <freeipa-users at redhat.com>
> Subject: Re: [Freeipa-users] Kerberized NFS Mount Issues
> Message-ID:
> <82E7C9A01FD0764CACDD35D10F5DFB6E68E086 at 001FSN2MPN1-045.001f.mgd2.msft.net>
>
> Content-Type: text/plain; charset="iso-8859-1"
>
>
>> 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.
> 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 "admin at EXAMPLE.LOCAL". If I'm not mistaken, this means that when you create files, NFS communicates the owner as "admin at example.local". 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: http://www.cs.indiana.edu/~robh/nfsv4+rhel6.html
>
> 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 <sbose at redhat.com>
> To: Genadi Postrilko <genadipost at gmail.com>
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Issues creating trust with AD.
> Message-ID: <20140217083433.GI15419 at localhost.localdomain>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Feb 15, 2014 at 12:14:58AM +0200, Genadi Postrilko wrote:
>> 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 :
>> https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/trust-ipa-subdomain.html
>>
>> 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 at ipaserver1 sbin]# kinit Administrator at ADEXAMPLE.COM
>> Password for Administrator at ADEXAMPLE.COM:
>> [root at ipaserver1 sbin]# klist
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: Administrator at ADEXAMPLE.COM
>>
>> Valid starting Expires Service principal
>> 02/14/14 07:50:21 02/14/14 17:50:20 krbtgt/ADEXAMPLE.COM at ADEXAMPLE.COM
>> renew until 02/15/14 07:50:21
>>
>> But logging in by "ssh" and "su" ended in failure:
>>
>> login as: Administrator at ADEXAMPLE.COM
>> Administrator at ADDC.COM@192.168.227.201's password:
>> Access denied
>>
>> After reading
>> http://www.freeipa.org/page/IPAv3_testing_AD_trust#Create_a_trust_to_an_AD_domaini
>> 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: Administrator at ADEXAMPLE.COM
>> Administrator at ADEXAMPLE.COM@192.168.227.201'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 at ipaserver1 sbin]# su Genadi at ADEXAMPLE.COM
>> su: user Genadi at ADEXAMPLE.COM 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 at ipaserver1 sbin]# wbinfo -u
>> [root at ipaserver1 sbin]#
>>
>> *wbinfo -u output:*
>> [root at ipaserver1 sbin]# wbinfo -g
>> admins
>> editors
>> default smb group
>> ad_users
>>
>> *wbinfo --online-status shows ADEXAMPLE is offline*
>> [root at ipaserver1 ~]# wbinfo --online-status
>> BUILTIN : online
>> LINUX : online
>> ADEXAMPLE : offline
>>
>> *getent for Administrator does return value.*
>> [root at ipaserver1 sbin]# getent passwd Administrator at ADEXAMPLE.COM
>> administrator at adexample.com:*:699000500:699000500::/home/
>> adexample.com/administrator:
>>
>> *getent for other AD users does not return value.*
>> [root at ipaserver1 sbin]# getent passwd Genadi at ADEXAMPLE.COM
>> [root at ipaserver1 sbin]#
>>
>>
>> *System info/configurations:*
>>
>> [root at ipaserver1 ~]# cat /etc/redhat-release
>> Red Hat Enterprise Linux Server release 6.2 Beta (Santiago)
>>
>> [root at 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 at ipaserver1 ~]# rpm -qa | grep sssd
>> sssd-1.9.2-129.el6.x86_64
>> sssd-client-1.9.2-129.el6.x86_64
>>
>> [root at 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
> 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
>
>> *SSSD*
>>
>> [root at 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 at ipaserver1 ~]# cat /etc/krb5.conf
>> includedir /var/lib/sss/pubconf/krb5.include.d/
>>
>> [logging]
>> default = FILE:/var/log/krb5libs.log
>> kdc = FILE:/var/log/krb5kdc.log
>> admin_server = FILE:/var/log/kadmind.log
>>
>> [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 = FILE:/etc/ipa/ca.crt
>> auth_to_local = RULE:[1:$1@$0](^.*@ADEXAMPLE.COM$)s/@
>> ADEXAMPLE.COM/@adexample.com/
>> 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):https://gist.github.com/anonymous/9006532
>> <https://gist.github.com/anonymous/9006532>*
>> Any insights on why only Administrator is recognized by the Trust? And why
>> extra step on AD was needed?
>> _______________________________________________
>> Freeipa-users mailing list
>> Freeipa-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-users
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 17 Feb 2014 09:46:53 +0100
> From: Pavel B?ezina <pbrezina at redhat.com>
> To: Steve Dainard <sdainard at miovision.com>
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Sudo denied on first attempt, allowed on
> second attempt
> Message-ID: <5301CC7D.6050903 at redhat.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 02/16/2014 01:19 AM, Steve Dainard wrote:
>> Just experienced the same issue on Fedora 20:
>>
>> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld
>> [sudo] password for sdainard-admin at miovision.corp:
>> sdainard-admin at miovision.corp is not allowed to run sudo on fed20. This
>> incident will be reported.
>> [sdainard-admin at miovision.corp@fed20 ~]$ sudo systemctl stop firewalld
>> [sudo] password for sdainard-admin at miovision.corp:
>> [sdainard-admin at miovision.corp@fed20 ~]$
>>
>> 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 <http://miovision.com/> | /Rethink Traffic/
>>
>> *Blog <http://miovision.com/blog> | **LinkedIn
>> <https://www.linkedin.com/company/miovision-technologies> | Twitter
>> <https://twitter.com/miovision> | Facebook
>> <https://www.facebook.com/miovision>*
>> ------------------------------------------------------------------------
>> 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 <sdainard at miovision.com
>> <mailto:sdainard at miovision.com>> 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:
>>
>> sdainard-admin at miovision.corp@ubu1310:~$ sudo su
>> [sudo] password for sdainard-admin at miovision.corp:
>> sdainard-admin at miovision.corp is not allowed to run sudo on ubu1310.
>> This incident will be reported.
>> sdainard-admin at miovision.corp@ubu1310:~$ sudo su
>> [sudo] password for sdainard-admin at miovision.corp:
>> root at ubu1310:/home/miovision.corp/sdainard-admin#
>>
>> 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 <http://miovision.com/> | /Rethink Traffic/
>>
>> *Blog <http://miovision.com/blog> | **LinkedIn
>> <https://www.linkedin.com/company/miovision-technologies> | Twitter
>> <https://twitter.com/miovision> | Facebook
>> <https://www.facebook.com/miovision>*
>> ------------------------------------------------------------------------
>> 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.
> 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 <jhrozek at redhat.com>
> To: Alexander Bokovoy <abokovoy at redhat.com>
> Cc: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] authentication against compat
> Message-ID: <20140217140300.GE7979 at hendrix.brq.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Fri, Feb 14, 2014 at 09:36:33AM +0200, Alexander Bokovoy wrote:
>> On Thu, 13 Feb 2014, Steve Dainard wrote:
>>> 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.
>> 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!
> 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 <jhrozek at redhat.com>
> To: freeipa-users at redhat.com
> Subject: Re: [Freeipa-users] Setting up sudo
> Message-ID: <20140217140810.GG7979 at hendrix.brq.redhat.com>
> Content-Type: text/plain; charset=us-ascii
>
> On Thu, Feb 13, 2014 at 06:30:37PM -0500, Dmitri Pal wrote:
>> On 02/13/2014 06:23 PM, Todd Maugh wrote:
>>> and If I am configuring the sud-ldap.conf
>>>
>>>
>>> what should it look like does any one have an example?
>>>
>> You have two options. Sudo can be integrated with SSSD or not.
>> If you want SUDO to be integrated then this should help: http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf
> Also man sssd-sudo should have some examples.
>
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 17 Feb 2014 14:25:57 +0000
> From: Andrew Holway <andrew.holway at gmail.com>
> To: Todd Maugh <tmaugh at boingo.com>
> Cc: "freeipa-users at redhat.com" <freeipa-users at redhat.com>
> Subject: Re: [Freeipa-users] Setting up sudo
> Message-ID:
> <CAEiui-s3LajmkiXF_7=0M_BvddHFoZg-51RR5jjyt303bi2Zmw at mail.gmail.com>
> 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. :)
>
> https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html
>
>
>
> On 13 February 2014 23:17, Todd Maugh <tmaugh at boingo.com> wrote:
>> 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
>> 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
>
> End of Freeipa-users Digest, Vol 67, Issue 88
> *********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20140217/19ad4bae/attachment.htm>
More information about the Freeipa-users
mailing list