[Freeipa-users] clarification regarding krb5.conf file
Hi List
correct me if i am wrong.
currently my client krb5.conf holding AD details. and my client is Solaris
here is my file.
bash-3.2# more /etc/krb5/krb5.conf
[libdefaults]
default_realm = KWTTESTDC.COM
[realms]
KWTTESTDC.COM = {
kdc = kwttestdc001.kwttestdc.com:88
admin_server = kwttestdc001.kwttestdc.com:749
}
[domain_realm]
.kwttestdc.com = KWTTESTDC.COM
kwttestdc.com = KWTTESTDC.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
please anyone varify this is right or wrong
Regards,
Ben
--
Yours Sincerely
*#!/usr/bin/env python #Mysignature.py :)*
Signature =Ben.T.George \n
Senior Technical Engineer \n
M.H Alshaya Co. W.L.L \n
kuwait \n
Phone : +965 - 50629829 \n
Print Signature
* Live like you will die tomorrow, learn like you will live forever *
--
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] FreeIPA Planet - blog aggregator - as alive!
Hello all, With increasing number of blogs and articles about FreeIPA, it is sometimes difficult to keep track of all of them. To help you - users interested in the FreeIPA project - we started a brand new FreeIPA Planet blog aggregator: http://planet.freeipa.org/ On this page, you can periodically check for new articles from various blogs related to the FreeIPA project or simply add the aggregated feed to your favorite RSS reader! Now comes the fun part. While the initial Planet incarnation already contains a decent list of sources, mostly blogs of FreeIPA developers, we would also like adding *your* FreeIPA related blogs to the list! Please just send as a link to the RSS feed of your blog (or rather category/tag devoted to the FreeIPA project) and we will add it to the list. Enjoy! -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team 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] clarification regarding krb5.conf file
HI
If i check IPA client machine enrolled with ipa-client, the krb5.conf file
looks like below:
[root@kwttestmrbs001 krb5.include.d]# more /etc/krb5.conf
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = SOLIPA.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
SOLIPA.LOCAL = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.solipa.local = SOLIPA.LOCAL
solipa.local = SOLIPA.LOCAL
and the includedir /var/lib/sss/pubconf/krb5.include.d/ is including :
[root@kwttestmrbs001 krb5.include.d]# more domain_realm_solipa_local
[domain_realm]
.kwttestdc.com = KWTTESTDC.COM
kwttestdc.com = KWTTESTDC.COM
anyone please help me to prepare proper krb5.conf file for solaris box
IPA Server is : kwtpocpbis01.solipa.local
Solaris (client) : kwttestsolaris10.solipa.local
Active Directory: kwttestdc001.kwttestdc.com
Regards,
Ben
On Wed, Jan 7, 2015 at 2:11 PM, Ben .T.George bentech4...@gmail.com wrote:
Hi List
correct me if i am wrong.
currently my client krb5.conf holding AD details. and my client is Solaris
here is my file.
bash-3.2# more /etc/krb5/krb5.conf
[libdefaults]
default_realm = KWTTESTDC.COM
[realms]
KWTTESTDC.COM = {
kdc = kwttestdc001.kwttestdc.com:88
admin_server = kwttestdc001.kwttestdc.com:749
}
[domain_realm]
.kwttestdc.com = KWTTESTDC.COM
kwttestdc.com = KWTTESTDC.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
please anyone varify this is right or wrong
Regards,
Ben
--
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] clarification regarding krb5.conf file
On 01/07/2015 06:36 AM, Ben .T.George wrote:
HI
If i check IPA client machine enrolled with ipa-client, the krb5.conf
file looks like below:
[root@kwttestmrbs001 krb5.include.d]# more /etc/krb5.conf
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = SOLIPA.LOCAL
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
[realms]
SOLIPA.LOCAL = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.solipa.local = SOLIPA.LOCAL
solipa.local = SOLIPA.LOCAL
and the includedir /var/lib/sss/pubconf/krb5.include.d/ is including :
[root@kwttestmrbs001 krb5.include.d]# more domain_realm_solipa_local
[domain_realm]
.kwttestdc.com http://kwttestdc.com = KWTTESTDC.COM
http://KWTTESTDC.COM
kwttestdc.com http://kwttestdc.com = KWTTESTDC.COM
http://KWTTESTDC.COM
anyone please help me to prepare proper krb5.conf file for solaris box
IPA Server is : kwtpocpbis01.solipa.local
Solaris (client) : kwttestsolaris10.solipa.local
Active Directory: kwttestdc001.kwttestdc.com
http://kwttestdc001.kwttestdc.com
Regards,
Ben
On Wed, Jan 7, 2015 at 2:11 PM, Ben .T.George bentech4...@gmail.com
mailto:bentech4...@gmail.com wrote:
Hi List
correct me if i am wrong.
currently my client krb5.conf holding AD details. and my client is
Solaris
here is my file.
bash-3.2# more /etc/krb5/krb5.conf
[libdefaults]
default_realm = KWTTESTDC.COM http://KWTTESTDC.COM
[realms]
KWTTESTDC.COM http://KWTTESTDC.COM = {
kdc = kwttestdc001.kwttestdc.com:88
http://kwttestdc001.kwttestdc.com:88
admin_server = kwttestdc001.kwttestdc.com:749
http://kwttestdc001.kwttestdc.com:749
}
[domain_realm]
.kwttestdc.com http://kwttestdc.com = KWTTESTDC.COM
http://KWTTESTDC.COM
kwttestdc.com http://kwttestdc.com = KWTTESTDC.COM
http://KWTTESTDC.COM
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
period = 1d
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
please anyone varify this is right or wrong
Regards,
Ben
OK, there seems to be a confusion at least on my side.
I see several option in this situation.
Option 1: You use your Solaris box with AD directly.
I do not think this is what you are trying to do. AFAIR you are trying
to connect it to IPA and use trusts. But direct connection should be
possible.
Option 2: Connect Solaris to IPA while it is in trust with AD
In this case you need to use LDAP for authentication and identity lookup
and point your client to compat tree. You can't use Kerberos. Kerberos
on Solaris does not know anything about the trust. If you make it use
Kerberos from IPA then you would be able to use only users from IPA. If
you need to use kerberos then we return to option 1.
Option 3. Create a split brain configuration: authentication using
kerberos will go to AD directly while identity will come from IPA's
compat tree.
This is potentially possible but this is an uncharted and not
recommended territory.
Option 4: Try to build SSSD for Solaris.
If it were easy we would have done it ourselves but patches are always
welcome . :-)
Option 5: Stop using Solaris.
--
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] Kerberos Tickets/kinit using Cygwin on Windows
On 01/07/2015 02:21 PM, Sumit Bose wrote:
On Wed, Jan 07, 2015 at 01:22:36PM -0500, Brad House wrote:
I have a need to 'kinit' from within a cygwin environment in order to
perform an svn checkout over ssh. However, I can't figure out how to
get this to work properly with FreeIPA. We had a MIT kerberos/
OpenLDAP authentication system prior to using FreeIPA and we had it
working there.
The windows machine itself is kerberized as per
http://www.freeipa.org/page/Windows_authentication_against_FreeIPA
so I can log in using the kerberos user via the standard windows login,
however I don't believe that is relevant to cygwin since it uses its own
config.
Next, I generated an /etc/krb5.conf file within cygwin as appropriate
for my domain (DNS SRV records don't appear to work so I had to fully
configure it with my ipa servers listed, etc ... which is basically
an identical config just with some new URLs to what was previously
working). It was derived originally from here:
http://computing.fnal.gov/authentication/krb5conf/Windows/krb5.conf
Also, the cygwin /etc/krb5.keytab is what was generated via ipa-getkeytab
from the FreeIPA windows config docs (linked earlier).
Initially I received these errors:
Jan 07 11:42:45 ipa1. krb5kdc[31975](info): AS_REQ (2 etypes {3 1})
10.100.10.112: BAD_ENCRYPTION_TYPE: bhouse@ for krbtgt/@, KDC has
no support for encryption type
It appeared the kerberos within cygwin is only advertising des encryption
types even though stronger ones are configured in my krb5.conf.
Ok, so I allowed weak crypto to the krb5kdc on the freeipa server following
the same procedure as from this mailing list entry (which was for a different
purpose):
https://www.redhat.com/archives/freeipa-users/2014-November/msg00246.html
Which appears similar to the NFS workarounds but also includes modifications
for krb5kdc.conf:
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/kerb-nfs.html
Now I'm receiving these errors in the logs:
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32006](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:30 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
looks like the client is resending as AS_REQ without proper pre-auth
data. Which version of cygwin are you using? Can you check with
'klist -V' which
Re: [Freeipa-users] Switch to 3rd party SSL
Andrew Chin wrote: Hello, I want to switch our FreeIPA 3.3.5 from using the FreeIPA CA self signed certificate to one signed by a commercial CA that browsers will recognize. The documentation at http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP says The certificate in mysite.crt must be signed by the CA used when installing FreeIPA.” Does this preclude me from installing the commercial cert? If not, should I just follow the directions for IPA 4.1? Thanks, Andrew Chin That is rather confusing isn't it. IMHO It should really say that the cert is signed by your 3rd party CA. You'll also want to make sure that the issuing CA is trusted in your NSS databases as well. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa host-add and service add command to add solaris 10
Ben .T.George wrote:
HI
thanks for the replay.
i was trying for keytab and getting below error.
[root@kwtpocpbis01 ~]# ipa-getkeytab -s kwtpocpbis01.solipa.local -p
host/kwttestsolaris10.solipa.local -k /tmp/krb5.keytab -e des-cbc-crc
Operation failed! All enctypes provided are unsupported
my krb5.conf looks like below:
[libdefaults]
default_realm = SOLIPA.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
default_ccache_name = KEYRING:persistent:%{uid}
allow_weak_crypto = true
what will be issue with my command?
You haven't configured enough. Follow Alexander's instructions here:
https://www.redhat.com/archives/freeipa-users/2014-November/msg00246.html
You'll also need to restart the krb5kdc service.
rob
Regards,
Ben
On Tue, Jan 6, 2015 at 11:35 PM, Rob Crittenden rcrit...@redhat.com
mailto:rcrit...@redhat.com wrote:
Ben .T.George wrote:
HI
i was trying to ass solaris 10 client from command line. Host add
comand
went successfully and service add for /host is giving error.
please check below output and help me to solve this
[root@kwtpocpbis01 ~]# ipa host-add --force
--ip-address=172.16.107.107
kwttestsolaris10.solipa.local
--
Added host kwttestsolaris10.solipa.local
--
Host name: kwttestsolaris10.solipa.local
Principal name: host/kwttestsolaris10.solipa.local@SOLIPA.LOCAL
Password: False
Keytab: False
Managed by: kwttestsolaris10.solipa.local
[root@kwtpocpbis01 ~]# ipa service-add
host/kwttestsolaris10.solipa.local
ipa: ERROR: You must enroll a host in order to create a host service
what this means ipa: ERROR: You must enroll a host in order to
create a
host service . I can see the host from IPA web front end. that means
host is added noe.? or this is pointing to another service
The host service is implicit and lives within the host. You don't need
to (nor can you) add it.
If you want to get a keytab for it just use ipa-getkeytab to fetch it.
rob
--
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] a fix - fedora domain vs rhel domain
Here is the snippet with the error: 2015-01-07T14:04:57Z DEBUG Adding CA certificates to the IPA NSS database. 2015-01-07T14:04:57Z DEBUG Starting external process 2015-01-07T14:04:57Z DEBUG args='/usr/bin/certutil' '-d' '/etc/ipa/nssdb' '-A' '-n' 'ANOTHER.COM IPA CA' '-t' 'CT,C,C' 2015-01-07T14:04:57Z DEBUG Process finished, return code=0 2015-01-07T14:04:57Z DEBUG stdout= 2015-01-07T14:04:57Z DEBUG stderr= 2015-01-07T14:04:57Z DEBUG Starting external process 2015-01-07T14:04:57Z DEBUG args='/usr/bin/update-ca-trust' 2015-01-07T14:04:58Z DEBUG Process finished, return code=1 2015-01-07T14:04:58Z DEBUG stdout= 2015-01-07T14:04:58Z DEBUG stderr=p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute p11-kit: failed to find certificates: The device is invalid or unrecognizable 2015-01-07T14:04:58Z ERROR Could not update systemwide CA trust database: Command ''/usr/bin/update-ca-trust'' returned non-zero exit status 1 2015-01-07T14:04:58Z DEBUG Attempting to add CA certificates to the default NSS database. 2015-01-07T14:04:58Z DEBUG Starting external process 2015-01-07T14:04:58Z DEBUG args='/usr/bin/certutil' '-d' '/etc/pki/nssdb' '-A' '-n' 'ANOTHER.COM IPA CA' '-t' 'CT,C,C' 2015-01-07T14:04:58Z DEBUG Process finished, return code=255 2015-01-07T14:04:58Z DEBUG stdout= 2015-01-07T14:04:58Z DEBUG stderr=certutil: could not decode certificate: SEC_ERROR_REUSED_ISSUER_AND_SERIAL: You are attempting to import a cert with the same issuer/serial as an existing cert, but that is not the same cert. 2015-01-07T14:04:58Z ERROR Failed to add ANOTHER.COM IPA CA to the default NSS database. 2015-01-07T14:04:58Z WARNING Installation failed. As this is IPA server, changes will not be rolled back. On 1/7/15 7:19 AM, Martin Kosek wrote: On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, 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] a fix - fedora domain vs rhel domain
On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, 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
[Freeipa-users] Switch to 3rd party SSL
Hello, I want to switch our FreeIPA 3.3.5 from using the FreeIPA CA self signed certificate to one signed by a commercial CA that browsers will recognize. The documentation at http://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP says The certificate in mysite.crt must be signed by the CA used when installing FreeIPA.” Does this preclude me from installing the commercial cert? If not, should I just follow the directions for IPA 4.1? Thanks, Andrew Chin -- 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] a fix - fedora domain vs rhel domain
Indeed you are correct - it was NOT the problem. Double checking the logs - showed an old ca.crt file from a previous install (something that should be done in the uninstall jobs - remove ALL the old folders, including /etc/ipa which has old certs, etc.) Thanks for the tip to look elsewhere - I made a bad assumption. Janelle On 1/7/15 7:19 AM, Martin Kosek wrote: On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, 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] a fix - fedora domain vs rhel domain
On 01/07/2015 04:42 PM, Janelle wrote: Indeed you are correct - it was NOT the problem. Good! Double checking the logs - showed an old ca.crt file from a previous install (something that should be done in the uninstall jobs - remove ALL the old folders, including /etc/ipa which has old certs, etc.) The certificate is supposed to be removed during client uninstall, since FreeIPA 3.2. Upstream ticket: https://fedorahosted.org/freeipa/ticket/3537 If you reproduce the problem with current versions, it is a bug... Thanks for the tip to look elsewhere - I made a bad assumption. Janelle On 1/7/15 7:19 AM, Martin Kosek wrote: On 01/07/2015 02:51 PM, Janelle wrote: Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 Hi Janelle, Yes, this should have been resolved in https://fedorahosted.org/freeipa/ticket/4562 CCing Jan. Are you sure it is caused by this problem? Can you add a snippet of the ipaclient-install.log with the actual failures? Your install snippet does not help that much. Can you please also check that you have the right FreeIPA platform file loaded? At least giving us output from this grep should help: $ grep domainname /usr/lib/python2.7/site-packages/ipaplatform/services.py Thanks, 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
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! 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? 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: /usr/lib64/ipa/certmonger/renew_ca_cert auditSigningCert cert-pki-ca track: yes auto-renew: yes Request ID '20130410022008': status: NEED_CSR stuck: no key pair storage:
[Freeipa-users] Kerberos Tickets/kinit using Cygwin on Windows
I have a need to 'kinit' from within a cygwin environment in order to
perform an svn checkout over ssh. However, I can't figure out how to
get this to work properly with FreeIPA. We had a MIT kerberos/
OpenLDAP authentication system prior to using FreeIPA and we had it
working there.
The windows machine itself is kerberized as per
http://www.freeipa.org/page/Windows_authentication_against_FreeIPA
so I can log in using the kerberos user via the standard windows login,
however I don't believe that is relevant to cygwin since it uses its own
config.
Next, I generated an /etc/krb5.conf file within cygwin as appropriate
for my domain (DNS SRV records don't appear to work so I had to fully
configure it with my ipa servers listed, etc ... which is basically
an identical config just with some new URLs to what was previously
working). It was derived originally from here:
http://computing.fnal.gov/authentication/krb5conf/Windows/krb5.conf
Also, the cygwin /etc/krb5.keytab is what was generated via ipa-getkeytab
from the FreeIPA windows config docs (linked earlier).
Initially I received these errors:
Jan 07 11:42:45 ipa1. krb5kdc[31975](info): AS_REQ (2 etypes {3 1})
10.100.10.112: BAD_ENCRYPTION_TYPE: bhouse@ for krbtgt/@, KDC has
no support for encryption type
It appeared the kerberos within cygwin is only advertising des encryption
types even though stronger ones are configured in my krb5.conf.
Ok, so I allowed weak crypto to the krb5kdc on the freeipa server following
the same procedure as from this mailing list entry (which was for a different
purpose):
https://www.redhat.com/archives/freeipa-users/2014-November/msg00246.html
Which appears similar to the NFS workarounds but also includes modifications
for krb5kdc.conf:
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/kerb-nfs.html
Now I'm receiving these errors in the logs:
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32006](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for krbtgt/@,
Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:30 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
And on the cygwin console I get:
$ kinit bhouse
Password for bhouse@:
kinit: Looping detected inside krb5_get_in_tkt while getting initial credentials
So I think this is _better_, however I don't know where to go from here.
Any help would be greatly
Re: [Freeipa-users] Kerberos Tickets/kinit using Cygwin on Windows
On Wed, Jan 07, 2015 at 01:22:36PM -0500, Brad House wrote:
I have a need to 'kinit' from within a cygwin environment in order to
perform an svn checkout over ssh. However, I can't figure out how to
get this to work properly with FreeIPA. We had a MIT kerberos/
OpenLDAP authentication system prior to using FreeIPA and we had it
working there.
The windows machine itself is kerberized as per
http://www.freeipa.org/page/Windows_authentication_against_FreeIPA
so I can log in using the kerberos user via the standard windows login,
however I don't believe that is relevant to cygwin since it uses its own
config.
Next, I generated an /etc/krb5.conf file within cygwin as appropriate
for my domain (DNS SRV records don't appear to work so I had to fully
configure it with my ipa servers listed, etc ... which is basically
an identical config just with some new URLs to what was previously
working). It was derived originally from here:
http://computing.fnal.gov/authentication/krb5conf/Windows/krb5.conf
Also, the cygwin /etc/krb5.keytab is what was generated via ipa-getkeytab
from the FreeIPA windows config docs (linked earlier).
Initially I received these errors:
Jan 07 11:42:45 ipa1. krb5kdc[31975](info): AS_REQ (2 etypes {3 1})
10.100.10.112: BAD_ENCRYPTION_TYPE: bhouse@ for krbtgt/@, KDC has
no support for encryption type
It appeared the kerberos within cygwin is only advertising des encryption
types even though stronger ones are configured in my krb5.conf.
Ok, so I allowed weak crypto to the krb5kdc on the freeipa server following
the same procedure as from this mailing list entry (which was for a different
purpose):
https://www.redhat.com/archives/freeipa-users/2014-November/msg00246.html
Which appears similar to the NFS workarounds but also includes modifications
for krb5kdc.conf:
http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/kerb-nfs.html
Now I'm receiving these errors in the logs:
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32006](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for
krbtgt/@, Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for
krbtgt/@, Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): AS_REQ (2
etypes {3 1}) 10.100.10.112: NEEDED_PREAUTH: bhouse@ for
krbtgt/@, Additional pre-authentication required
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:29 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
Jan 07 12:39:30 ipa1.p10jax.auth.monetra.com krb5kdc[32005](info): DISPATCH:
repeated (retransmitted?) request from 10.100.10.112, resending previous
response
looks like the client is resending as AS_REQ without proper pre-auth
data. Which version of cygwin are you
[Freeipa-users] a fix - fedora domain vs rhel domain
Hello fellow IPAers I know this has been written about before - the python scripts and fedora-domain vs rhel-domain on RHEL/CentOs 7. The question is - was there a permanent fix yet? I continue to run into it during installs and have to edit python files to get the client install to not error out duruing the server install. This is of course with CentOS 7 and IPA 4.1.2. Any options/comments? Thank you Janelle (install snippet) Done. Restarting the directory server Restarting the KDC Restarting the certificate server Sample zone file for bind has been created in /tmp/sample.zone.vTMlCB.db Restarting the web server Configuration of client side components failed! ipa-client-install returned: Command ''/usr/sbin/ipa-client-install' '--on-master' '--unattended' '--domain' 'another.com' '--server' 'ipa1.another.com' '--realm' 'ANOTHER.COM' '--hostname' 'ipa1.another.com'' returned non-zero exit status 1 -- 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
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 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 provide your sssd and nsswitch configuration files. (/etc/nsswitch.conf, /etc/sssd/sssd.conf) We need to be sure that sudo integration with sssd is configured properly. OK - changed the sudo rule to only !authenticate and then logged in manually... ssh -tt rundeck@$MY_SERVER thus removing the 'requiretty' problem and then when I ran my sudo command, it still asked me for a password. I have the sudo debug log attached to this email. I can
