Re: [Freeipa-users] sudo !requiretty !authenticate
On 01/08/2015 10:45 AM, Pavel Březina wrote: On 01/07/2015 06:32 PM, Craig White wrote: Still struggling with this... $ sudo /sbin/service pe-puppet restart [sudo] password for rundeck: Stopping puppet: [ OK ] Starting puppet: [ OK ] So it asks for the password even though, via FreeIPA it isn't required... $ sudo -l Matching Defaults entries for rundeck 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 User rundeck may run the following commands on this host: (root) ALL (ALL) NOPASSWD: ALL Hi, thank you, I was just going to ask you for sudo -l. I believe that the problem is that (root) ALL rule takes precedence. Or to be more precise, the first rule that matches is always applied, unless sudoOrder attribute is present (but that is not supported by IPA, is it?). JFTR, sudoOrder *is* supported in FreeIPA, since FreeIPA 3.3.4 (upstream ticket https://fedorahosted.org/freeipa/ticket/4107). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Confused with certificate renewal ipa-server-3.0.0.0-37.el6.x86_64
On 01/07/2015 06:43 PM, John Desantis wrote: Hello all, Just an update on this issue for anyone else who experiences a similar issue. It looks like the automatic renewal of the certificates failed on our master due the certmonger service being stuck. I stopped the service, stopped IPA services, and then reset the date to a few days prior to the expiration. I then (following a mailing list post) restarted IPA and then certmonger. At this point, I checked the status of the certificates and saw that they were changing. Only the Server-Cert in /etc/httpd/alias was complaining this time of not being able to contact the CA. Another certmonger service restart corrected the issue. I can now re-provision nodes accordingly! Ok, good to hear! The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Thank you, John DeSantis 2015-01-06 15:50 GMT-05:00 John Desantis desan...@mail.usf.edu: Hello all, Looking at the various online documentation regarding certificate renewals: http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0 http://www.freeipa.org/page/Certmonger https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/cas.html I have to admit that I am completely confused on how to proceed given that the links above reference external CA's. The certificate was created in house (no external issuer) from what I can tell (openssl x509 -issuer and via IPA GUI). Thankfully(?), none of the certificates listed via 'getcert list' have a status of CA_UNREACHABLE, although all of them state NEED_CSR. I'll paste the contents below, sanitized of couse. # getcert list Number of certificates and requests being tracked: 8. Request ID '20130110185936': status: NEED_CSR stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE.COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-EXAMPLE.COM/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE.COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2015-01-11 18:59:35 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE.COM track: yes auto-renew: yes Request ID '20130110190008': status: NEED_CSR stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2015-01-11 19:00:07 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130110190034': status: NEED_CSR stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=ipa.example.com,O=EXAMPLE.COM expires: 2015-01-11 19:00:34 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/restart_httpd track: yes auto-renew: yes Request ID '20130410022007': status: NEED_CSR stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='377154649534' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=EXAMPLE.COM subject: CN=CA Audit,O=EXAMPLE.COM expires: 2014-12-31 18:58:42 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command:
[Freeipa-users] Mount cifs share using kerberos
Hello, I have a samba share on the freeipa 4.1 server that I want to mount from another client that is part of the ipa domain I've tried: mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5 Shouldn't I be able to do the mount this way? -- john -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo !requiretty !authenticate
On 01/07/2015 06:32 PM, Craig White wrote: Still struggling with this... $ sudo /sbin/service pe-puppet restart [sudo] password for rundeck: Stopping puppet: [ OK ] Starting puppet: [ OK ] So it asks for the password even though, via FreeIPA it isn't required... $ sudo -l Matching Defaults entries for rundeck 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 User rundeck may run the following commands on this host: (root) ALL (ALL) NOPASSWD: ALL Hi, thank you, I was just going to ask you for sudo -l. I believe that the problem is that (root) ALL rule takes precedence. Or to be more precise, the first rule that matches is always applied, unless sudoOrder attribute is present (but that is not supported by IPA, is it?). Try removing the rule (root) ALL, restarting sssd and wait until the cache is refreshed and see if that works. And all of the info is provided previously/below that should be needed including the sudo debug log in yesterday's email if anyone has the time to help me figure out what is going wrong here. -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Craig White Sent: Tuesday, January 06, 2015 10:17 AM To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] sudo !requiretty !authenticate -Original Message- From: Lukas Slebodnik [mailto:lsleb...@redhat.com] Sent: Tuesday, January 06, 2015 3:11 AM To: Craig White Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] sudo !requiretty !authenticate On (06/01/15 10:21), Pavel Březina wrote: On 01/05/2015 07:32 PM, Craig White wrote: Hi - reply at bottom -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Monday, January 05, 2015 4:33 AM To: Craig White; freeipa-users@redhat.com; Pavel Brezina Subject: Re: [Freeipa-users] sudo !requiretty !authenticate On 01/02/2015 07:47 PM, Craig White wrote: Subject pretty much says it all. Starting to play around with rundeck and was thinking it would be nice if I could create a user that had the ability to sudo, without password, a public key and the ability to run commands. But the use of 'sudo' gets me an error that says it requires a tty to run sudo. So I tried by creating a sudo rule that has options '!requiretty !authenticate' but it still complains that I need a tty. Is there a FreeIPA method that I am lacking? Craig White System Administrator O 623-201-8179 M 602-377-9752 [cid:image001.png@01CF86FE.42D51630] SkyTouch Technology 4225 E. Windrose Dr. Phoenix, AZ 85032 CCing Pavel to advise. From top of my head - did you try clearing SSSD cache before calling the sudo command again? Did you enter the options in the FreeIPA SUDO entry correctly? Maybe the problem is that each option should be filed as a separate attribute value and you entered it as one combined attribute value. Martin Thanks Martin Unclear how to 'clear SSSD cache' so I restarted SSSD service on the testing box but it didn't help. $ ipa sudorule-show --all Rule name: rundeck dn: ipaUniqueID=XX,cn=sudorules,cn=sudo,dc=stt,dc=local Rule name: rundeck Enabled: TRUE Host category: all Command category: all RunAs User category: all Users: rundeck Sudo Option: !requiretty, !authenticate ipauniqueid: XX objectclass: ipaassociation, ipasudorule At this point, !requiretty and !authenticate are separate options but I have previously tried them as a bundle together but the results are the same... sudo: sorry, you must have a tty to run sudo :-( (client system) # rpm -qa | egrep 'ipa|sssd' sssd-ldap-1.11.6-30.el6.x86_64 libipa_hbac-1.11.6-30.el6.x86_64 python-sssdconfig-1.11.6-30.el6.noarch sssd-ipa-1.11.6-30.el6.x86_64 sssd-client-1.11.6-30.el6.x86_64 sssd-common-1.11.6-30.el6.x86_64 sssd-ad-1.11.6-30.el6.x86_64 sssd-1.11.6-30.el6.x86_64 python-iniparse-0.3.1-2.1.el6.noarch libipa_hbac-python-1.11.6-30.el6.x86_64 sssd-krb5-common-1.11.6-30.el6.x86_64 sssd-krb5-1.11.6-30.el6.x86_64 sssd-common-pac-1.11.6-30.el6.x86_64 ipa-python-3.0.0-42.el6.x86_64 sssd-proxy-1.11.6-30.el6.x86_64 ipa-client-3.0.0-42.el6.x86_64 Hi, just to be sure that the problem is indeed in options - the rule without any sudoOption and with only one of them does work, right? Can you send us sudo debug log? You can enable debug log by putting the following line in /etc/sudo.conf: Debug sudo /var/log/sudo.log all@debug It will help as well if you
Re: [Freeipa-users] Mount cifs share using kerberos
On Thu, 8 Jan 2015 10:01:50 +0100 John Obaterspok john.obaters...@gmail.com wrote: Hello, I have a samba share on the freeipa 4.1 server that I want to mount from another client that is part of the ipa domain I've tried: mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5 Shouldn't I be able to do the mount this way? -- john You should be able to, what's the error ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Confused with certificate renewal ipa-server-3.0.0.0-37.el6.x86_64
Hello all, I didn't reply to the list, so I'll forward in my response. The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Would file corruption within the file of the Request ID in /var/lib/certmonger/request have anything to do with this? autorenew=1 monitor=1 ca_name=dogtag-ipa-retrieve-agent-submit ca_profile=ipaCert submitted=20141228050011 cert=ESC[?1034h-BEGIN CERTIFICATE- I checked a few other random client nodes (and the master) and none of them are showing this corruption in their requests. I attempted to fix the corruption (editing the file) and subsequently restart certmonger with no luck. Thanks, John DeSantis Thanks, John DeSantis 2015-01-08 13:26 GMT-05:00 John Desantis desan...@mail.usf.edu: Hello all, The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Would file corruption within the file of the Request ID in /var/lib/certmonger/request have anything to do with this? autorenew=1 monitor=1 ca_name=dogtag-ipa-retrieve-agent-submit ca_profile=ipaCert submitted=20141228050011 cert=ESC[?1034h-BEGIN CERTIFICATE- I checked a few other random client nodes (and the master) and none of them are showing this corruption in their requests. I attempted to fix the corruption (editing the file) and subsequently restart certmonger with no luck. Thanks, John DeSantis 2015-01-08 8:10 GMT-05:00 Martin Kosek mko...@redhat.com: On 01/07/2015 06:43 PM, John Desantis wrote: Hello all, Just an update on this issue for anyone else who experiences a similar issue. It looks like the automatic renewal of the certificates failed on our master due the certmonger service being stuck. I stopped the service, stopped IPA services, and then reset the date to a few days prior to the expiration. I then (following a mailing list post) restarted IPA and then certmonger. At this point, I checked the status of the certificates and saw that they were changing. Only the Server-Cert in /etc/httpd/alias was complaining this time of not being able to contact the CA. Another certmonger service restart corrected the issue. I can now re-provision nodes accordingly! Ok, good to hear! The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Thank you, John DeSantis 2015-01-06 15:50 GMT-05:00 John Desantis desan...@mail.usf.edu: Hello all, Looking at the various online documentation regarding certificate renewals: http://www.freeipa.org/page/Howto/CA_Certificate_Renewal#Procedure_in_IPA_.3C_4.0
[Freeipa-users] Wildcard type usage in sudo rules with FreeIPA.
I am trying to figure out how (or if its even possible) to use wildcard type sudo rules in FreeIPA. I setup Sudo rules usage and so far seems to be working - at least if I setup ALL type rules for Hosts. However it looks like I have to add specifc allowed hosts in the GUI as they either appear in the host list or add them in the External option box. However that makes it messy / non scalable if I want to create a group of users that have access to a large number of host types, say db servers or something. File based sudo rules allow for constructs such as: someusername *dbserver* = /opt/appname/admintools/run_admin_tools.sh Which allows someuser to have sudo options on any hostname matching *dbserver* and then run the command allowed. This all currently seems doable in IPA except the wildcard part for hostnames / domains etc. Apologizes if I missed this in the docs. Thanks in advance for any ideas (command line methods?) Running: ipa-server-3.0.0-37 sssd-1.9.2 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Configure also-notify for freeipa DNS zones
Hi, The docs state this: DNS slaves will transfer the whole zone periodically as is specified in zone's SOA record. DNS masters also send DNS NOTIFY messages to inform slaves about a change asynchronously. I have a need to execute zone transfers from my IPA server(s) to non-IPA slaves and I would like the IPA servers to send notifies each time the zone is updated/reloaded (eg, the also-notify option in BIND). Currently, the zone transfer is only executed once the refresh timer in the SOA expires. I don't see an option within IPA to configure the BIND also-notify option. How can I make my IPA DNS servers send notify's to my non-IPA slave servers so that zone transfers occur immediately after IPA zone updates? Thanks, Josh -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Wildcard type usage in sudo rules with FreeIPA.
Thanks Dmitri! That at least tells me to stop attempting things that are going to not work. I will look into the automember info. Currently I don't think that will work for us since we using IPA essentially as just LDAP and not using the IPA client (but using SSSD on the hosts) and I don't register hosts directly in IPA. We did not really want / need that extra overhead but did like the other integrated components of IPA. Thanks so much for the info. On Thu, Jan 8, 2015 at 10:15 AM, Dmitri Pal d...@redhat.com wrote: On 01/08/2015 10:00 AM, Lance Reed wrote: I am trying to figure out how (or if its even possible) to use wildcard type sudo rules in FreeIPA. I setup Sudo rules usage and so far seems to be working - at least if I setup ALL type rules for Hosts. However it looks like I have to add specifc allowed hosts in the GUI as they either appear in the host list or add them in the External option box. However that makes it messy / non scalable if I want to create a group of users that have access to a large number of host types, say db servers or something. File based sudo rules allow for constructs such as: someusername *dbserver* = /opt/appname/admintools/run_admin_tools.sh Which allows someuser to have sudo options on any hostname matching *dbserver* and then run the command allowed. This all currently seems doable in IPA except the wildcard part for hostnames / domains etc. Apologizes if I missed this in the docs. Thanks in advance for any ideas (command line methods?) I think to solve this problem with IPA you need to define sudo rules for a host group dbserver (or whatever name you choose) and then use automemebership [1] rules to automatically manage the membership of you servers in that group. Starting 4.1 automembership rules can be reapplied to already existing entries. [2]. Before that the rules applied only to new entries being created. [1] - http://www.port389.org/docs/389ds/design/automember-design.html (I do not think there is an IPA design page but IPA uses DS plugin) [2] - http://www.freeipa.org/page/V4/Automember_rebuild_membership HTH Thanks Dmitri Running: ipa-server-3.0.0-37 sssd-1.9.2 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo !requiretty !authenticate
Craig White wrote:
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Martin Kosek
Sent: Thursday, January 08, 2015 5:30 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate
On 01/08/2015 10:45 AM, Pavel Březina wrote:
On 01/07/2015 06:32 PM, Craig White wrote:
Still struggling with this...
$ sudo /sbin/service pe-puppet restart
[sudo] password for rundeck:
Stopping puppet: [ OK ]
Starting puppet: [ OK ]
So it asks for the password even though, via FreeIPA it isn't required...
$ sudo -l
Matching Defaults entries for rundeck 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
User rundeck may run the following commands on this host:
(root) ALL
(ALL) NOPASSWD: ALL
Hi,
thank you, I was just going to ask you for sudo -l. I believe that the
problem is that (root) ALL rule takes precedence. Or to be more
precise, the first rule that matches is always applied, unless
sudoOrder attribute is present (but that is not supported by IPA, is it?).
JFTR, sudoOrder *is* supported in FreeIPA, since FreeIPA 3.3.4 (upstream
ticket https://fedorahosted.org/freeipa/ticket/4107).
I see said the blind man. Obviously the root/ALL rule is part and parcel of
RHEL distribution of sudo package.
$ rpm -q ipa-server
ipa-server-3.0.0-42.el6.x86_64
$ cat sudoOrder.ldif
dn: cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
$ ldapmodify -x -h `hostname` -D cn=Directory Manager -W -f sudoOrder.ldif
Enter LDAP Password:
modifying entry cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
ldap_modify: No such object (32)
additional info: Range Check error
bummer :-(
You have a typo, suoders instead of sudoers.
You might also experiment with order in the sudoers entry in
/etc/nsswitch.conf, try sss files. Or if you don't intend on storing any
rules in files, perhaps drop it.
$ ldapsearch -x -h `hostname` -D cn=directory manager -W -b
cn=plugins,cn=config '(cn=sudoers)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base cn=plugins,cn=config with scope subtree
# filter: (cn=sudoers)
# requesting: ALL
#
# sudoers, Schema Compatibility, plugins, config
dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
schema-compat-entry-attribute: objectclass=sudoRole
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%{ex
ternalUser})
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%der
ef_f(\memberUser\,\(objectclass=posixAccount)\,\uid\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%der
ef_rf(\memberUser\,\((objectclass=ipaUserGroup)(!(objectclass=posixGroup)
))\,\member\,\(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\,\
uid\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%%%d
eref_f(\memberUser\,\(objectclass=posixGroup)\,\cn\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,+%de
ref_f(\memberUser\,\(objectclass=ipaNisNetgroup)\,\cn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%{ex
ternalHost})
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%der
ef_f(\memberHost\,\(objectclass=ipaHost)\,\fqdn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%der
ef_rf(\memberHost\,\((objectclass=ipaHostGroup)(!(objectclass=mepOriginEn
try)))\,\member\,\(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\,\
fqdn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,+%de
ref_f(\memberHost\,\((objectclass=ipaHostGroup)(objectclass=mepOriginEntr
y))\,\cn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,+%de
ref_f(\memberHost\,\(objectclass=ipaNisNetgroup)\,\cn\))
schema-compat-entry-attribute: sudoCommand=%ifeq(cmdCategory,all,ALL,%d
eref(\memberAllowCmd\,\sudoCmd\))
schema-compat-entry-attribute: sudoCommand=%ifeq(cmdCategory,all,ALL,%d
eref_r(\memberAllowCmd\,\member\,\sudoCmd\))
schema-compat-entry-attribute: sudoCommand=!%deref(memberDenyCmd,sudoCmd)
schema-compat-entry-attribute: sudoCommand=!%deref_r(memberDenyCmd,member,
sudoCmd)
schema-compat-entry-attribute: sudoRunAsUser=%{ipaSudoRunAsExtUser}
schema-compat-entry-attribute:
Re: [Freeipa-users] Wildcard type usage in sudo rules with FreeIPA.
On 01/08/2015 10:00 AM, Lance Reed wrote: I am trying to figure out how (or if its even possible) to use wildcard type sudo rules in FreeIPA. I setup Sudo rules usage and so far seems to be working - at least if I setup ALL type rules for Hosts. However it looks like I have to add specifc allowed hosts in the GUI as they either appear in the host list or add them in the External option box. However that makes it messy / non scalable if I want to create a group of users that have access to a large number of host types, say db servers or something. File based sudo rules allow for constructs such as: someusername *dbserver* = /opt/appname/admintools/run_admin_tools.sh Which allows someuser to have sudo options on any hostname matching *dbserver* and then run the command allowed. This all currently seems doable in IPA except the wildcard part for hostnames / domains etc. Apologizes if I missed this in the docs. Thanks in advance for any ideas (command line methods?) I think to solve this problem with IPA you need to define sudo rules for a host group dbserver (or whatever name you choose) and then use automemebership [1] rules to automatically manage the membership of you servers in that group. Starting 4.1 automembership rules can be reapplied to already existing entries. [2]. Before that the rules applied only to new entries being created. [1] - http://www.port389.org/docs/389ds/design/automember-design.html (I do not think there is an IPA design page but IPA uses DS plugin) [2] - http://www.freeipa.org/page/V4/Automember_rebuild_membership HTH Thanks Dmitri Running: ipa-server-3.0.0-37 sssd-1.9.2 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo !requiretty !authenticate
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Martin Kosek
Sent: Thursday, January 08, 2015 5:30 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate
On 01/08/2015 10:45 AM, Pavel Březina wrote:
On 01/07/2015 06:32 PM, Craig White wrote:
Still struggling with this...
$ sudo /sbin/service pe-puppet restart
[sudo] password for rundeck:
Stopping puppet: [ OK ]
Starting puppet: [ OK ]
So it asks for the password even though, via FreeIPA it isn't required...
$ sudo -l
Matching Defaults entries for rundeck 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
User rundeck may run the following commands on this host:
(root) ALL
(ALL) NOPASSWD: ALL
Hi,
thank you, I was just going to ask you for sudo -l. I believe that the
problem is that (root) ALL rule takes precedence. Or to be more
precise, the first rule that matches is always applied, unless
sudoOrder attribute is present (but that is not supported by IPA, is it?).
JFTR, sudoOrder *is* supported in FreeIPA, since FreeIPA 3.3.4 (upstream ticket
https://fedorahosted.org/freeipa/ticket/4107).
I see said the blind man. Obviously the root/ALL rule is part and parcel of
RHEL distribution of sudo package.
$ rpm -q ipa-server
ipa-server-3.0.0-42.el6.x86_64
$ cat sudoOrder.ldif
dn: cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
$ ldapmodify -x -h `hostname` -D cn=Directory Manager -W -f sudoOrder.ldif
Enter LDAP Password:
modifying entry cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
ldap_modify: No such object (32)
additional info: Range Check error
bummer :-(
$ ldapsearch -x -h `hostname` -D cn=directory manager -W -b
cn=plugins,cn=config '(cn=sudoers)'
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base cn=plugins,cn=config with scope subtree
# filter: (cn=sudoers)
# requesting: ALL
#
# sudoers, Schema Compatibility, plugins, config
dn: cn=sudoers,cn=Schema Compatibility,cn=plugins,cn=config
schema-compat-entry-attribute: objectclass=sudoRole
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%{ex
ternalUser})
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%der
ef_f(\memberUser\,\(objectclass=posixAccount)\,\uid\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%der
ef_rf(\memberUser\,\((objectclass=ipaUserGroup)(!(objectclass=posixGroup)
))\,\member\,\(|(objectclass=ipaUserGroup)(objectclass=posixAccount))\,\
uid\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,%%%d
eref_f(\memberUser\,\(objectclass=posixGroup)\,\cn\))
schema-compat-entry-attribute: sudoUser=%ifeq(userCategory,all,ALL,+%de
ref_f(\memberUser\,\(objectclass=ipaNisNetgroup)\,\cn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%{ex
ternalHost})
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%der
ef_f(\memberHost\,\(objectclass=ipaHost)\,\fqdn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,%der
ef_rf(\memberHost\,\((objectclass=ipaHostGroup)(!(objectclass=mepOriginEn
try)))\,\member\,\(|(objectclass=ipaHostGroup)(objectclass=ipaHost))\,\
fqdn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,+%de
ref_f(\memberHost\,\((objectclass=ipaHostGroup)(objectclass=mepOriginEntr
y))\,\cn\))
schema-compat-entry-attribute: sudoHost=%ifeq(hostCategory,all,ALL,+%de
ref_f(\memberHost\,\(objectclass=ipaNisNetgroup)\,\cn\))
schema-compat-entry-attribute: sudoCommand=%ifeq(cmdCategory,all,ALL,%d
eref(\memberAllowCmd\,\sudoCmd\))
schema-compat-entry-attribute: sudoCommand=%ifeq(cmdCategory,all,ALL,%d
eref_r(\memberAllowCmd\,\member\,\sudoCmd\))
schema-compat-entry-attribute: sudoCommand=!%deref(memberDenyCmd,sudoCmd)
schema-compat-entry-attribute: sudoCommand=!%deref_r(memberDenyCmd,member,
sudoCmd)
schema-compat-entry-attribute: sudoRunAsUser=%{ipaSudoRunAsExtUser}
schema-compat-entry-attribute: sudoRunAsUser=%deref(ipaSudoRunAs,uid)
schema-compat-entry-attribute: sudoRunAsUser=%ifeq(ipaSudoRunAsUserCategory,
all,ALL,%%%deref_f(\ipaSudoRunAs\,\(objectclass=posixGroup)\,\cn\)
)
schema-compat-entry-attribute: sudoRunAsGroup=%{ipaSudoRunAsExtGroup}
schema-compat-entry-attribute: sudoOption=%{ipaSudoOpt}
Re: [Freeipa-users] Wildcard type usage in sudo rules with FreeIPA.
On 01/08/2015 10:42 AM, Lance Reed wrote: Thanks Dmitri! That at least tells me to stop attempting things that are going to not work. I will look into the automember info. Currently I don't think that will work for us since we using IPA essentially as just LDAP and not using the IPA client (but using SSSD on the hosts) and I don't register hosts directly in IPA. We did not really want / need that extra overhead but did like the other integrated components of IPA. SSSD is the client. ipa-client is just a configuration script that configures SSSD. Having a host entry has a lot of benefits for access control and policies. It seems that you sort of a bit force limited yourself with the approach you have taken. Thanks so much for the info. On Thu, Jan 8, 2015 at 10:15 AM, Dmitri Pal d...@redhat.com wrote: On 01/08/2015 10:00 AM, Lance Reed wrote: I am trying to figure out how (or if its even possible) to use wildcard type sudo rules in FreeIPA. I setup Sudo rules usage and so far seems to be working - at least if I setup ALL type rules for Hosts. However it looks like I have to add specifc allowed hosts in the GUI as they either appear in the host list or add them in the External option box. However that makes it messy / non scalable if I want to create a group of users that have access to a large number of host types, say db servers or something. File based sudo rules allow for constructs such as: someusername *dbserver* = /opt/appname/admintools/run_admin_tools.sh Which allows someuser to have sudo options on any hostname matching *dbserver* and then run the command allowed. This all currently seems doable in IPA except the wildcard part for hostnames / domains etc. Apologizes if I missed this in the docs. Thanks in advance for any ideas (command line methods?) I think to solve this problem with IPA you need to define sudo rules for a host group dbserver (or whatever name you choose) and then use automemebership [1] rules to automatically manage the membership of you servers in that group. Starting 4.1 automembership rules can be reapplied to already existing entries. [2]. Before that the rules applied only to new entries being created. [1] - http://www.port389.org/docs/389ds/design/automember-design.html (I do not think there is an IPA design page but IPA uses DS plugin) [2] - http://www.freeipa.org/page/V4/Automember_rebuild_membership HTH Thanks Dmitri Running: ipa-server-3.0.0-37 sssd-1.9.2 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Confused with certificate renewal ipa-server-3.0.0.0-37.el6.x86_64
John Desantis wrote: Hello all, I didn't reply to the list, so I'll forward in my response. The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Would file corruption within the file of the Request ID in /var/lib/certmonger/request have anything to do with this? autorenew=1 monitor=1 ca_name=dogtag-ipa-retrieve-agent-submit ca_profile=ipaCert submitted=20141228050011 cert=ESC[?1034h-BEGIN CERTIFICATE- I checked a few other random client nodes (and the master) and none of them are showing this corruption in their requests. I attempted to fix the corruption (editing the file) and subsequently restart certmonger with no luck. Thanks, John DeSantis Thanks, John DeSantis 2015-01-08 13:26 GMT-05:00 John Desantis desan...@mail.usf.edu: Hello all, The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Would file corruption within the file of the Request ID in /var/lib/certmonger/request have anything to do with this? autorenew=1 monitor=1 ca_name=dogtag-ipa-retrieve-agent-submit ca_profile=ipaCert submitted=20141228050011 cert=ESC[?1034h-BEGIN CERTIFICATE- I checked a few other random client nodes (and the master) and none of them are showing this corruption in their requests. I attempted to fix the corruption (editing the file) and subsequently restart certmonger with no luck. Thanks, John DeSantis Ah, that sounds familiar. See https://fedorahosted.org/freeipa/ticket/4064 The change is quite small, you might try manually changing it. Then a certmonger restart might fix it. rob 2015-01-08 8:10 GMT-05:00 Martin Kosek mko...@redhat.com: On 01/07/2015 06:43 PM, John Desantis wrote: Hello all, Just an update on this issue for anyone else who experiences a similar issue. It looks like the automatic renewal of the certificates failed on our master due the certmonger service being stuck. I stopped the service, stopped IPA services, and then reset the date to a few days prior to the expiration. I then (following a mailing list post) restarted IPA and then certmonger. At this point, I checked the status of the certificates and saw that they were changing. Only the Server-Cert in /etc/httpd/alias was complaining this time of not being able to contact the CA. Another certmonger service restart corrected the issue. I can now re-provision nodes accordingly! Ok, good to hear! The only remaining hiccup is now the replica's certmonger service keeps dying while failing to re-issue the ipaCert in /etc/httpd/alias. Log snippets are below: Jan 7 12:17:02 python: certmonger restarted httpd Jan 7 12:17:03 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA and saved. Jan 7 12:17:08 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias is no longer valid. Jan 7 12:17:40 certmonger: Certificate named ipaCert in token NSS Certificate DB in database /etc/httpd/alias issued by CA but not saved. The IPA services are running and the machine can be accessed (queries issued, web GUI, etc.) Would anyone have an idea of why a replica would have issues renewing the ipaCert? CCing Jan to advise, he is the most experienced in this area. Thank you, John DeSantis 2015-01-06 15:50 GMT-05:00 John Desantis
Re: [Freeipa-users] sudo !requiretty !authenticate
-Original Message-
From: Rob Crittenden [mailto:rcrit...@redhat.com]
Sent: Thursday, January 08, 2015 9:33 AM
To: Craig White; Martin Kosek; Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate
Craig White wrote:
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of Martin Kosek
Sent: Thursday, January 08, 2015 5:30 AM
To: Pavel Březina; freeipa-users@redhat.com
Subject: Re: [Freeipa-users] sudo !requiretty !authenticate
On 01/08/2015 10:45 AM, Pavel Březina wrote:
On 01/07/2015 06:32 PM, Craig White wrote:
Still struggling with this...
$ sudo /sbin/service pe-puppet restart
[sudo] password for rundeck:
Stopping puppet: [ OK ]
Starting puppet: [ OK ]
So it asks for the password even though, via FreeIPA it isn't required...
$ sudo -l
Matching Defaults entries for rundeck 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
User rundeck may run the following commands on this host:
(root) ALL
(ALL) NOPASSWD: ALL
Hi,
thank you, I was just going to ask you for sudo -l. I believe that
the problem is that (root) ALL rule takes precedence. Or to be more
precise, the first rule that matches is always applied, unless
sudoOrder attribute is present (but that is not supported by IPA, is it?).
JFTR, sudoOrder *is* supported in FreeIPA, since FreeIPA 3.3.4 (upstream
ticket https://fedorahosted.org/freeipa/ticket/4107).
I see said the blind man. Obviously the root/ALL rule is part and parcel of
RHEL distribution of sudo package.
$ rpm -q ipa-server
ipa-server-3.0.0-42.el6.x86_64
$ cat sudoOrder.ldif
dn: cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
changetype: modify
add: schema-compat-entry-attribute
schema-compat-entry-attribute: sudoOrder=%{sudoOrder}
$ ldapmodify -x -h `hostname` -D cn=Directory Manager -W -f
sudoOrder.ldif Enter LDAP Password:
modifying entry cn=suoders,cn=Schema Compatibility,cn=plugins,cn=config
ldap_modify: No such object (32)
additional info: Range Check error
bummer :-(
You have a typo, suoders instead of sudoers.
You might also experiment with order in the sudoers entry in
/etc/nsswitch.conf, try sss files. Or if you don't intend on storing any rules
in files, perhaps drop it.
Thanks for catching my typo - my bad.
This is interesting. First tried 'sss files' and then just 'sss' for sudoers in
nsswitch.conf but no go.
$ sudo -l
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for rundeck:
Matching Defaults entries for rundeck on this host:
!requiretty
User rundeck may run the following commands on this host:
(root) ALL
(ALL) NOPASSWD: ALL
So !authenticate doesn't show up even though I have had the rule in ipa for 2
days now.
$ ipa sudorule-show rundeck
Rule name: rundeck
Enabled: TRUE
Host category: all
Command category: all
RunAs User category: all
RunAs Group category: all
Users: rundeck
Sudo Option: !authenticate
That '(root) ALL' rule doesn't come from /etc/sudoers as I thought because
nsswitch.conf presently only uses sss for sudoers. I still don't see where it
actually comes from though...
$ ldapsearch -x -h `hostname` -D cn=Directory Manager -W -b
ou=sudoers,dc=stt,dc=local
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base ou=sudoers,dc=stt,dc=local with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# sudoers, stt.local
dn: ou=sudoers,dc=stt,dc=local
objectClass: extensibleObject
ou: sudoers
# defaults, sudoers, stt.local
dn: cn=defaults,ou=sudoers,dc=stt,dc=local
objectClass: sudoRole
sudoOption: !requiretty
cn: defaults
# rundeck, sudoers, stt.local
dn: cn=rundeck,ou=sudoers,dc=stt,dc=local
objectClass: sudoRole
sudoUser: rundeck
sudoHost: ALL
sudoCommand: ALL
sudoRunAsUser: ALL
sudoOption: !authenticate
cn: rundeck
# puppet, sudoers, stt.local
dn: cn=puppet,ou=sudoers,dc=stt,dc=local
objectClass: sudoRole
sudoUser: %puppet
sudoHost: +puppet
sudoCommand: ALL
cn: puppet
# sysengineers, sudoers, stt.local
dn: cn=sysengineers,ou=sudoers,dc=stt,dc=local
objectClass: sudoRole
sudoUser: %sysengineer
sudoHost: ALL
sudoCommand: ALL
cn: sysengineers
# sysadmins, sudoers,
Re: [Freeipa-users] Confused with certificate renewal ipa-server-3.0.0.0-37.el6.x86_64
On 01/08/2015 09:12 PM, John Desantis wrote: Martin, Rob, and Nalin, The patch worked for me (https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=1357eade4c5086e6c837a49f3008616317f88e5f), thank you so much for the assistance! The process was simple. I'll quickly outline it for other users faced with the same issue. 1.) Apply patch. 2.) Ensure certmonger wasn't running (in my case it just crashed after a few minutes); 3.) Edit the request in question in /var/lib/certmonger/requests to remove the corruption; 4.) Restart certmonger. Great to hear! But as I said, this fix is part of RHEL-6.6, so alternative for 1) is update IPA to RHEL-6.6 Not sure if steps 2-4 are required though, I would hope that just updateresubmit is enough. Again, I really appreciate the assistance on such a great product. Obviously, there would be pizza and beer if you were all local! Heh... Come to next DevConf (http://www.devconf.cz/) and you will have a chance to meet (most of) us, if you are interested! ;-) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem starting IPA after reboot
okay, I see. the below line caused a *new* keytab to be created and caused smb from starting. 1) ipa-getkeytab -s ipaserver -p cifs/ipaserver.my.lan -k /etc/krb5.keytab I've fixed this and now ipa starts fine again. 2015-01-08 20:31 GMT+01:00 John Obaterspok john.obaters...@gmail.com: Hello, I was trying out cifs mount when I ran into some problem where smb failed to load. What I've done was: 1) ipa-getkeytab -s ipaserver -p cifs/ipaserver.my.lan -k /etc/krb5.keytab 2) pdbedit -L on ipaserver (which failed since I'm using registry) Then I got strange errors and tried reboot. Now initially smb failed to start, then after a minute or two ipa + kadmin also fails. I've noticed selinux complains about: - SELinux is preventing /usr/sbin/krb5kdc from write access on the sock_file /var/lib/sss/pipes/pac. - SELinux is preventing /usr/sbin/krb5kdc from connectto access on the unix_stream_socket /var/lib/sss/pipes/pac. I see the following in journal -b 20:19:44 smbd[2065]: [2015/01/08 20:19:44.736247, 0] ../source3/smbd/server.c:1269(main) 20:19:44 smbd[2065]: standard input is not a socket, assuming -D option 20:19:44 systemd[1]: smb.service: Supervising process 2066 which is not our child. We'll most likely not notice when it exits. 20:19:44 smbd[2066]: [2015/01/08 20:19:44.803085, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:44 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:44 smbd[2066]: [2015/01/08 20:19:44.803985, 0] ../source3/lib/smbldap.c:998(smbldap_connect_system) 20:19:44 smbd[2066]: failed to bind to server ldapi://%2fvar%2frun%2fslapd-MY-LAN.socket with dn=[Anonymous bind] Error: Local error 20:19:44 smbd[2066]: (unknown) 20:19:45 smbd[2066]: [2015/01/08 20:19:45.815968, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:45 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:46 smbd[2066]: [2015/01/08 20:19:46.826820, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:46 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:47 smbd[2066]: [2015/01/08 20:19:47.837775, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:47 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:48 smbd[2066]: [2015/01/08 20:19:48.848497, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:48 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:49 smbd[2066]: [2015/01/08 20:19:49.859177, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:49 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:50 smbd[2066]: [2015/01/08 20:19:50.869958, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:50 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:51 smbd[2066]: [2015/01/08 20:19:51.880575, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:51 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:52 smbd[2066]: [2015/01/08 20:19:52.890531, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:52 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:53 smbd[2066]: [2015/01/08 20:19:53.901092, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:53 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:54 smbd[2066]: [2015/01/08 20:19:54.912209, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:54 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:55 smbd[2066]: [2015/01/08 20:19:55.922373, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:55 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:56 smbd[2066]: [2015/01/08 20:19:56.932368, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:56 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:57 smbd[2066]: [2015/01/08 20:19:57.942731, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:57 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:58 smbd[2066]: [2015/01/08 20:19:58.953319, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:58 smbd[2066]: kerberos error: code=-1765328366, message=Clients credentials have been revoked 20:19:59 named-pkcs11[1536]: OSSLRSA.cpp(999): RSA verify failed (0x04091068) 20:19:59 named-pkcs11[1536]: pkcs11rsa_link.c:496: pkcs_C_VerifyFinal: Error = 0x00C0 20:19:59 named-pkcs11[1536]: OSSLRSA.cpp(999): RSA verify failed (0x04091068) 20:19:59 named-pkcs11[1536]: pkcs11rsa_link.c:496: pkcs_C_VerifyFinal: Error = 0x00C0 20:19:59 smbd[2066]: [2015/01/08 20:19:59.963057, 0] ipa_sam.c:4128(bind_callback_cleanup) 20:19:59 smbd[2066]: kerberos error:
Re: [Freeipa-users] Mount cifs share using kerberos
Hello, I've tried to do the following on the client (and also on the ipaserver itself) where I want to the the ipaserver share mounted. [root@ipaserver mnt]# mount -t cifs //ipaserver.MY.LAN/TheShare -o sec=krb5 mountpoint mount error(126): Required key not available Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) (root has an admin ticket aquired) Any hints for a newbie? -- john 2015-01-08 18:51 GMT+01:00 Simo Sorce s...@redhat.com: On Thu, 8 Jan 2015 10:01:50 +0100 John Obaterspok john.obaters...@gmail.com wrote: Hello, I have a samba share on the freeipa 4.1 server that I want to mount from another client that is part of the ipa domain I've tried: mount -t cifs //ipaserver.DOMAIN.LAN/share /mnt/point -o sec=krb5 Shouldn't I be able to do the mount this way? -- john You should be able to, what's the error ? Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] sudo !requiretty !authenticate
That '(root) ALL' rule doesn't come from /etc/sudoers as I thought because nsswitch.conf presently only uses sss for sudoers. I still don't see where it actually comes from though... What groups is rundeck a member of? - Bingo! Thanks Pavel/Rob Turns out that I had long forgotten that I added rundeck user to sysadmin group for HBAC reasons, inherited the sudo rules for that group which were killing me. Rundeck now workee! -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
