[Freeipa-users] Re: ID view is not overriding user attributes

2017-08-08 Thread Supratik Goswami via FreeIPA-users 
(Wed Aug  9 04:20:14 2017) [sssd[be[ipa.corp.example.com]]]
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with
[(&(objectClass=ipaUserOverride)(uid=supratik.goswami))][cn=Default Trust
View,cn=views,cn=accounts,dc=ipa,dc=corp,dc=example,dc=com]

What I could see here is that it is searching as 'supratik.goswami' and not
'supratik.gos...@ad.corp.example.com' which is the ID View user in the IPA.

How do I fix this?

On Wed, Aug 9, 2017 at 8:53 AM, Supratik Goswami 
wrote:

> Hello everyone,
>
> I have a trust setup between AD and IPA, I have created a user in the
> "Default Trust View" and
> updated the ssh public keys for that user.
>
> When I am trying to login to any Linux system using the ad user it is not
> able to find the keys.
>
> Here is the sshd debug log.
>
> Aug  9 03:04:01 host01 sshd[20102]: debug3: Running AuthorizedKeysCommand:
> "/usr/bin/sss_ssh_authorizedkeys supratik.gosw...@ad.corp.example.com" as
> "nobody"
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
> Aug  9 03:04:01 host01 sshd[20102]: debug1: temporarily_use_uid: 99/99
> (e=0/0)
> Aug  9 03:04:01 host01 sshd[20106]: debug3: sshd_selinux_setup_variables:
> setting execution context
> Aug  9 03:04:01 host01 sshd[20102]: debug2: key not found
> Aug  9 03:04:01 host01 sshd[20102]: debug1: restore_uid: 0/0
>
> My sshd_config file has the following entries
>
> AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
> AuthorizedKeysCommandUser nobody
>
> What could be the issue?
>
>
> Thanks
>
> --
> Warm Regards
>
> Supratik
>



-- 
Warm Regards

Supratik
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-08 Thread Fraser Tweedale via FreeIPA-users 
On Tue, Aug 08, 2017 at 11:40:54AM -0400, Rob Crittenden wrote:
> Michael Gusek via FreeIPA-users wrote:
> > Hi Fraser,
> > 
> > at the moment, i can't provide this logfile, i've moved that back to
> > have only new log lines. But a new new logfile is not created ??? In my
> > old logfile i have some lines after switch to basic auth, but before
> > setting time to past:
> >
> 
> The CA won't start with expired certs.
> 
> I'd set the time back to the past and ensure that the CA comes up. The
> debug log in that case should tell you what is going on. Be sure that
> ntpd is stopped.
> 
> Restarting certmonger should be sufficient to have it try renewal as it
> will see on startup that the certs need to be refreshed.
> 
> rob
>
Further, have a look at `getcert list` output, or
`certutil -d /etc/pki/pki-tomcat/alias -L -n `, to inspect
the Dogtag system certificates to work out their expiry dates.

Ensure that you restart IPA (`ipactl restart`) after setting the
clock back, so that services can reinitialise with certs that are
valid according to system time.

Cheers,
Fraser
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: mod_ldap apache

2017-08-08 Thread Per Qvindesland via FreeIPA-users 
Hi ivars 

Many thanks that's just what I was looking for.

Sorry about the iPad it should be ipa but it seems I am a victim of autocorrect 
藍

Regards
Per 



Sent from my Commodore 64

> On 8 Aug 2017, at 18:07, Ivars Strazdiņš via FreeIPA-users 
>  wrote:
> 
> Hi Per,
> could you define “working configuration” requirements and what’s iPad 
> specific?
> Anyway, below is my setup with Centos Apache to authenticate against IPA via 
> LDAP using either username (uid) or e-mail. No Kerberos or GSSAPI used, just 
> “pure” LDAP.
> Please note, IPA group “shareusers” membership is required. IPA host is 
> im.example.com
> With kind regards,
> Ivars
> 
> File /etc/httpd/access/ldap.conf 
> 
> AuthName   "File service login"
> # AuthBasicProviders are defined in ../conf.d/00-ldap.conf
> AuthBasicProvider  ldap-uid ldap-mail
> AuthType   Basic
> 
> # Even if AuthLDAPURL is defined in AuthnProviderAlias in 
> ../conf.d/00-ldap.conf and processed earlier
> # these directives are mandatory to authorize after authentication
> AuthLDAPURL
> ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?mail?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
> AuthLDAPInitialBindAsUser On
> AuthLDAPSearchAsUserOn
> AuthLDAPCompareAsUser   On
> 
> 
> File /etc/httpd/conf.d/00-ldap.conf
> 
> LDAPTrustedGlobalCert CA_BASE64 /etc/ipa/ca.crt
> 
> # AuthnProviderAlias must be defined here, it cannot be in VirtualHost 
> # because ../access/ldap.conf is VirtualHost level
> 
> # ldap-mail is tried last (after ldap-uid)
> 
> AuthLDAPURL
> ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?mail?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
>   # this one (last) must be authoritative
> # AuthLDAPBindAuthoritative off
> AuthLDAPInitialBindAsUser On
> AuthLDAPSearchAsUserOn
> AuthLDAPCompareAsUser   On
> AuthLDAPInitialBindPattern (.+)\@(.+) 
> uid=$1,cn=users,cn=accounts,dc=example,dc=com
> 
> 
> # ldap-uid is tried first
> 
> AuthLDAPURL 
> ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?uid?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
>   # first one is NOT authoritative
> AuthLDAPBindAuthoritative off
> AuthLDAPInitialBindAsUser On
> AuthLDAPSearchAsUserOn
> AuthLDAPCompareAsUser   On
> AuthLDAPInitialBindPattern (.+) 
> uid=$1,cn=users,cn=accounts,dc=example,dc=com
> 
> 
> 
>> On 2017. gada 8. aug., at 15:11, Per Qvindesland via FreeIPA-users 
>>  wrote:
>> 
>> Hi All
>> 
>> Does anyone have any working mod_ldap configuration for Centos 7 with apache 
>> 2.4.6 with iPad to share?
>> 
>> Regards
>> Per
>> 
>> 
>> 
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Correcting errors in the CA master certificate

2017-08-08 Thread Scott Stevson via FreeIPA-users 
Cool. We'll work on this some more and let you know how The Gathering goes.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Correcting errors in the CA master certificate

2017-08-08 Thread Rob Crittenden via FreeIPA-users 
Scott Stevson via FreeIPA-users wrote:
> Thanks, Rob.
> 
> Unfortunately my test in staging resulted in an expired dogtag cert.  The 
> staging environment didn't have any certificates that were due to expire soon 
> so I updated the xmlrpc_server variable on one of the four IPA hosts we have 
> to another one in the same AWS region and restarted certmonger.  I then 
> resubmitted the cert request for one of the ID's I have and suddenly a cert 
> that was due to expire later this year is now expired as of 2016.
> 
> STAGING
> Request ID '20170124164909':
>   status: MONITORING
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-retrieve-agent-submit
>   issuer: CN=Certificate Authority,O=COMPANY.LOCAL
>   subject: CN=IPA RA,O=COMPANY.LOCAL
>   expires: 2016-12-07 03:35:22 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command:
>   post-save command: /usr/lib64/ipa/certmonger/restart_httpd
>   track: yes
>   auto-renew: yes

For some things in IPA, like the Highlander, there can be only one.

An example of this is the CA responsible for renewing the CA subsystem
certificates (OCSP, the RA cert, etc).

During the renewal the updated certificates are stored in LDAP which is
replicated. The non-renewing masters monitor that location and fetch
updated certs from there.

So I'm guessing that the old cert is in LDAP and that got pulled down
for some reason, why I have no idea as certmonger should know better.
You can check to see what's in there by:

$ ldapsearch -Y GSSAPI -b 'cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=com

This will show the current ipaCert in more detail:

# certutil -L -d /etc/httpd/alias -n ipaCert

You can compare this to the output of the various other staging masters.

> And for completeness, I'm pasting the output of getcert list on prod so you 
> can see the cert that's due to expire in its entirety.
> PROD
> Request ID '20150827000358':
>   status: MONITORING
>   ca-error: Server at 
> "http://server-ns-1.our.domain.local:9180/ca/ee/ca/profileSubmit; replied: 1: 
> Server Internal Error
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-renew-agent
>   issuer: CN=Certificate Authority,O=COMPANY.LOCAL
>   subject: CN=IPA RA,O=COMPANY.LOCAL
>   expires: 2017-08-15 20:17:52 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
>   eku: id-kp-serverAuth,id-kp-clientAuth
>   pre-save command:
>   post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
>   track: yes
>   auto-renew: yes
> 

I still think updating the xmlrpc_server is the way forward. I can't
explain the mix-up.

ipa config-show should show you the currently configured renewal master.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Correcting errors in the CA master certificate

2017-08-08 Thread Scott Stevson via FreeIPA-users 
Thanks, Rob.

Unfortunately my test in staging resulted in an expired dogtag cert.  The 
staging environment didn't have any certificates that were due to expire soon 
so I updated the xmlrpc_server variable on one of the four IPA hosts we have to 
another one in the same AWS region and restarted certmonger.  I then 
resubmitted the cert request for one of the ID's I have and suddenly a cert 
that was due to expire later this year is now expired as of 2016.

STAGING
Request ID '20170124164909':
status: MONITORING
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-retrieve-agent-submit
issuer: CN=Certificate Authority,O=COMPANY.LOCAL
subject: CN=IPA RA,O=COMPANY.LOCAL
expires: 2016-12-07 03:35:22 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes

And for completeness, I'm pasting the output of getcert list on prod so you can 
see the cert that's due to expire in its entirety.
PROD
Request ID '20150827000358':
status: MONITORING
ca-error: Server at 
"http://server-ns-1.our.domain.local:9180/ca/ee/ca/profileSubmit; replied: 1: 
Server Internal Error
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=COMPANY.LOCAL
subject: CN=IPA RA,O=COMPANY.LOCAL
expires: 2017-08-15 20:17:52 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert
track: yes
auto-renew: yes

Apologies if this is painful.  We appreciate the back and forth here.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Failed Upgrade?

2017-08-08 Thread Ian Harding via FreeIPA-users 

On 8/7/17 1:44 AM, thierry bordaz wrote:




On 08/07/2017 09:22 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

On 08/04/2017 11:02 PM, Ian Harding via FreeIPA-users wrote:

On 8/4/17 2:16 AM, Florence Blanc-Renaud wrote:


On 08/03/2017 11:13 PM, Ian Harding via FreeIPA-users wrote:

On 08/03/2017 12:28 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had 
apparently had
updates run but had not been restarted. ipactl says 
pki-tomcatd

would
not start.

Strangely, the actual service appears to be running:



dogtag is an application within tomcat so tomcat can 
run without

dogtag
running.

We need to see more of the dogtag debug log to see what 
is going on.




It looks like an authentication problem...

[28/Jul/2017:10:08:47][localhost-startStop-1]: SSL 
handshake happened
Could not connect to LDAP server host 
seattlenfs.bpt.rocks port 636
Error netscape.ldap.LDAPException: Authentication failed 
(49)




Hi,

dogtag stores its internal data in the LDAP server and 
needs to

establish a secure LDAP connection. You can check how this
connection is configured in 
/etc/pki/pki-tomcat/ca/CS.cfg, look for

the lines:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert 
cert-pki-ca

internaldb.ldapconn.host=vm-...
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn

authtype can be SslClientAuth (authentication with a ssl
certificate) or BasicAuth (authentication with a bind DN and
password stored in 
/var/lib/pki/pki-tomcat/conf/password.conf).


You can use this information to manually check the 
credentials. For

instance with sslclientauth:

export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
export LDAPTLS_CERT='subsystemCert cert-pki-ca'

ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y 
EXTERNAL
(provide the password from 
/etc/pki/pki-tomcat/alias/pwdfile.txt)




I found this:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert 
cert-pki-ca

internaldb.ldapconn.cloneReplicationPort=389
...

and when I try the ldapsearch I am presented with a prompt 
to provide

a pin/password

Please enter pin, password, or pass phrase for security 
token 'ldap(0)':


but there is no password file...


Hi,

you are right, in 4.4. there is no pwdfile.txt and the 
password can be
found in /var/lib/pki/pki-tomcat/conf/password.conf (with 
the tag

internal=...)

Can you check if the password with the tag internal=... 
allows to read

the keys from the NSS db?
certutil -K -d /etc/pki/pki-tomcat/alias
(provide password)


That works...

# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS 
User Private

Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan)
< 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a   NSS 
Certificate

DB:auditSigningCert cert-pki-ca
< 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert
cert-pki-ca
< 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403   NSS 
Certificate

DB:ocspSigningCert cert-pki-ca
< 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert
cert-pki-ca
< 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856   NSS 
Certificate

DB:subsystemCert cert-pki-ca

But this doesn't (with the same password from password.conf)

# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y 
EXTERNAL
Please enter pin, password, or pass phrase for security 
token 'ldap(0)':

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

That password is getting me somewhere though, since if I put 
in a

nonsense or incorrect password it just prompts over and over.


Let's step back a second. You upgraded from what to what?


There wasn't much of a change... I just assumed someone ran 
yum upgrade and didn't restart, then the power outage... it 
looks like not much of a version change though.


# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed: 
ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed: 
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated:

[Freeipa-users] Re: Correcting errors in the CA master certificate

2017-08-08 Thread Rob Crittenden via FreeIPA-users 
Scott Stevson via FreeIPA-users wrote:
> Hey Rob,
> 
> It's the NSSDB cert.  Here's some console output that might be helpful.
> 
> PROD [root@server-ns-1 var]# getcert list | grep -A10 20150827000358
> Request ID '20150827000358':
>   status: MONITORING
>   ca-error: Server at 
> "http://server-ns-1.our.domain.local:9180/ca/ee/ca/profileSubmit; replied: 1: 
> Server Internal Error
>   stuck: no
>   key pair storage: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
>   certificate: 
> type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
> Certificate DB'
>   CA: dogtag-ipa-renew-agent
>   issuer: CN=Certificate Authority,O=COMPANY.LOCAL
>   subject: CN=IPA RA,O=COMPANY.LOCAL
>   expires: 2017-08-15 20:17:52 UTC
>   key usage: 
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> 
> As for how this happened:  We're not entirely sure yet but the working theory 
> is the SRE who provisioned the new CA master didn't fully remove all 
> references to the old one.  I need to track down a few more people and 
> details in order to answer this fully.
> 
> As for the CA debug log.  I don't see any references to failures per se, and 
> I'm wondering if there's something I can do to force an error that'll be 
> useful to you.  Again, the failure I referenced earlier is a our Nagios check 
> for certmonger that simply reacts to the output `getcert list` returns.  
> Versions of this are all I see in the debug logs.
> 
> [08/Aug/2017:15:39:31][TP-Processor9]: CMSServlet: curDate=Tue Aug 08 
> 15:39:31 UTC 2017 id=caProfileSubmitSSLClient time=62

certmonger doesn't use SRV records to lookup an IPA master. Update the
xmlrpc_server entry in /etc/ipa/default.conf to point to a working IPA
server and that should fix this for you after a certmonger restart.

There is a bug open on this we just haven't gotten to it yet.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: mod_ldap apache

2017-08-08 Thread Ivars Strazdiņš via FreeIPA-users 
Hi Per,
could you define “working configuration” requirements and what’s iPad specific?
Anyway, below is my setup with Centos Apache to authenticate against IPA via 
LDAP using either username (uid) or e-mail. No Kerberos or GSSAPI used, just 
“pure” LDAP.
Please note, IPA group “shareusers” membership is required. IPA host is 
im.example.com
With kind regards,
Ivars

File /etc/httpd/access/ldap.conf 

AuthName   "File service login"
# AuthBasicProviders are defined in ../conf.d/00-ldap.conf
AuthBasicProvider  ldap-uid ldap-mail
AuthType   Basic

# Even if AuthLDAPURL is defined in AuthnProviderAlias in 
../conf.d/00-ldap.conf and processed earlier
# these directives are mandatory to authorize after authentication
AuthLDAPURL
ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?mail?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
AuthLDAPInitialBindAsUser On
AuthLDAPSearchAsUserOn
AuthLDAPCompareAsUser   On


File /etc/httpd/conf.d/00-ldap.conf

LDAPTrustedGlobalCert CA_BASE64 /etc/ipa/ca.crt

# AuthnProviderAlias must be defined here, it cannot be in VirtualHost 
# because ../access/ldap.conf is VirtualHost level

# ldap-mail is tried last (after ldap-uid)

AuthLDAPURL
ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?mail?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
# this one (last) must be authoritative
# AuthLDAPBindAuthoritative off
AuthLDAPInitialBindAsUser On
AuthLDAPSearchAsUserOn
AuthLDAPCompareAsUser   On
AuthLDAPInitialBindPattern (.+)\@(.+) 
uid=$1,cn=users,cn=accounts,dc=example,dc=com


# ldap-uid is tried first

AuthLDAPURL 
ldaps://im.example.com/cn=users,cn=accounts,dc=example,dc=com?uid?sub?(memberOf=cn=shareusers,cn=groups,cn=accounts,dc=example,dc=com)
# first one is NOT authoritative
AuthLDAPBindAuthoritative off
AuthLDAPInitialBindAsUser On
AuthLDAPSearchAsUserOn
AuthLDAPCompareAsUser   On
AuthLDAPInitialBindPattern (.+) 
uid=$1,cn=users,cn=accounts,dc=example,dc=com



> On 2017. gada 8. aug., at 15:11, Per Qvindesland via FreeIPA-users 
>  wrote:
> 
> Hi All
> 
> Does anyone have any working mod_ldap configuration for Centos 7 with apache 
> 2.4.6 with iPad to share?
> 
> Regards
> Per
> 
> 
> 
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FIPA OTP 2FA

2017-08-08 Thread Jochen Hein via FreeIPA-users 
saidireddy ranabothu via FreeIPA-users
 writes:

> I have enabled password+OTP authentication for a user and able to sync
> tokens and SSH.
>
> While ssh to server using FIPA credentials it's asking authentication in
> two steps as First Factor and Second Factor .
>
> But i just want to give it in a single line password ,Can any one suggest
> how to do it as  a single line password?

Try just pressing Enter when asked for second factor.

Jochen

-- 
This space is intentionally left blank.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: HBAC vs Sudo

2017-08-08 Thread Justin Stephenson via FreeIPA-users 

On 08/08/2017 12:02 PM, Steve Weeks via FreeIPA-users wrote:
We are running FreeIPA 4.4.  Even though sudo is listed as one of the 
services in the HBAC rule, it seems like only the Sudo rules are what 
really controls sudo.  Sudo ignores what is in the HBAC rules.


Is this expected behavior?  It doesn't really which way it really works, 
we are more concerned that we might be confused and screwing something up.


HBAC rules restrict and grant access to certain services based on how 
these rules are configured. If HBAC evaluation prevents access for a 
user to sudo then sudo commands will be denied for that user regardless 
of how sudo rules are configured. HBAC Access is evaluated first and 
must be allowed for sudo operations to succeed, sudo and HBAC should be 
considered as two separate operations in IPA.


You can test the HBAC component using the 'ipa hbactest' command with 
'--service=sudo' to see if sudo access would be allowed on a certain 
host for a certain user.


If this is still confusing, could you provide an example of what you 
mean exactly ?


Kind regards,
Justin Stephenson



Thanks,
Steve



___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Correcting errors in the CA master certificate

2017-08-08 Thread Scott Stevson via FreeIPA-users 
Hey Rob,

It's the NSSDB cert.  Here's some console output that might be helpful.

PROD [root@server-ns-1 var]# getcert list | grep -A10 20150827000358
Request ID '20150827000358':
status: MONITORING
ca-error: Server at 
"http://server-ns-1.our.domain.local:9180/ca/ee/ca/profileSubmit; replied: 1: 
Server Internal Error
stuck: no
key pair storage: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate: 
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS 
Certificate DB'
CA: dogtag-ipa-renew-agent
issuer: CN=Certificate Authority,O=COMPANY.LOCAL
subject: CN=IPA RA,O=COMPANY.LOCAL
expires: 2017-08-15 20:17:52 UTC
key usage: 
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment

As for how this happened:  We're not entirely sure yet but the working theory 
is the SRE who provisioned the new CA master didn't fully remove all references 
to the old one.  I need to track down a few more people and details in order to 
answer this fully.

As for the CA debug log.  I don't see any references to failures per se, and 
I'm wondering if there's something I can do to force an error that'll be useful 
to you.  Again, the failure I referenced earlier is a our Nagios check for 
certmonger that simply reacts to the output `getcert list` returns.  Versions 
of this are all I see in the debug logs.

[08/Aug/2017:15:39:31][TP-Processor9]: CMSServlet: curDate=Tue Aug 08 15:39:31 
UTC 2017 id=caProfileSubmitSSLClient time=62
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] HBAC vs Sudo

2017-08-08 Thread Steve Weeks via FreeIPA-users 
We are running FreeIPA 4.4.  Even though sudo is listed as one of the
services in the HBAC rule, it seems like only the Sudo rules are what
really controls sudo.  Sudo ignores what is in the HBAC rules.

Is this expected behavior?  It doesn't really which way it really works, we
are more concerned that we might be confused and screwing something up.

Thanks,
Steve
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Creating certificate for master domain

2017-08-08 Thread Rob Crittenden via FreeIPA-users 
Rafał Wądołowski via FreeIPA-users wrote:
> We have host which is registered and have http service with one domain
> e.g. xyz.intra.example.com.
> 
> But we want to add another site with domain intra.example.com, and we
> need to enroll certificate for that domain, but we can't because the
> hostname of these host is xyz.intra.example.com.
> 
> Is it possible to force client service with specified domain? and create
> certificate for it?

I still don't quite understand the question. What does the hostname have
to do with anything?

Can I try to restate the problem? Is it that you have something like
www.washingtonpost.com and you have a cert for the HTTP service so
someone can go to https://www.washingtonpost.com/?

And now you also want users to be able to drop the www and go right to
the domain and not get a cert warning? Like https://washingtonpost.com ?
(FTR their server cert has like 100 wildcards as subject-alt-names).

IPA can only issue certs for hosts, services and users. It can't issue a
certificate for a domain and can't issue wildcard certs by default.

You might want to see if this fits your needs:
https://www.freeipa.org/page/Howto/Wildcard_certificates

> BR,
> Rafał
> 
> On 03/08/17 16:03, Rob Crittenden via FreeIPA-users wrote:
>> Rafał Wądołowski wrote:
>>> Okey, but how can I create certificate for domain intra.example.com?
>>>
>>> I can't create host, because the hostname is required. When I try to add
>>> service, I got output that principal is required.
>> Like I said, every cert needs to live in a bucket (user, service, etc)
>> so since domain can't fit into one, you can't issue a cert for it.
>>
>> What would it be used for? I'm not sure how meaningful a domain name in
>> a cert is, but it could be a use-case we missed.
>>
>> rob
>>
>>>
>>> Pozdrawiam,
>>>
>>> Rafał Wądołowski
>>>
>>> On 02/08/17 15:55, Rob Crittenden via FreeIPA-users wrote:
 Rafał Wądołowski via FreeIPA-users wrote:
> Hi,
>
> I have freeipa 4.4 cluster with CN intra.example.com.
>
> We developed intranet on this same domain, but I can't create a valid
> certificate for it.
>
> I can't create service, because hostname is required. Is it other way to
> sign the CSR?
>
> What is the good practice for creating https certificates?
>
 I don't understand the question.

 A certificate can only be issued for objects that IPA knows about, a
 service, host or user.

 rob
 ___
 FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
 To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>> ___
>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> 
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-08 Thread Rob Crittenden via FreeIPA-users 
Michael Gusek via FreeIPA-users wrote:
> Hi Fraser,
> 
> at the moment, i can't provide this logfile, i've moved that back to
> have only new log lines. But a new new logfile is not created ??? In my
> old logfile i have some lines after switch to basic auth, but before
> setting time to past:
>

The CA won't start with expired certs.

I'd set the time back to the past and ensure that the CA comes up. The
debug log in that case should tell you what is going on. Be sure that
ntpd is stopped.

Restarting certmonger should be sufficient to have it try renewal as it
will see on startup that the certs need to be refreshed.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] reverse zone after install?

2017-08-08 Thread Kat via FreeIPA-users 

Hi All,

If you setup DNS but did not enable the reverse zone during the initial 
install, is there a way to add/enable it after the fact? I can script 
adding in all the PTR records, but wanted to find out how to 
create/enable the reverse zone once you have already installed.


Thanks

K
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Unable to login with AD users

2017-08-08 Thread Eddleman, David via FreeIPA-users 
Hello,

I have created a FreeIPA solution using Red Hat’s IDM product.
FreeIPA version: 4.5.0
OS version: RHEL 7.4

I have successfully installed the server portion and can authenticate to it 
using local IDM users, such as the ‘admin’ user. I have created a one-way trust 
between the IPA realm and an AD realm successfully, as `ipa trust-show` 
demonstrates, returning the SID of the domain. I have also created the local 
POSIX and external groups and mapped them. `ipa group-show ` 
returns the external member SID just fine.

However, I cannot authenticate in the server over SSH using one of those AD 
users. I’ve checked the HBAC rules and they are fine. One thing I noticed when 
monitoring the securelog when testing is that the IDM users make a call to 
pam_sss, as expected, but the AD users do not. I have tried multiple ways of 
passing the user and all are rejected -- user@netbios, user@domainfqdn, 
netbios\user, and domainfqdn\user.

The user in question is in a single group in AD, and it has been tested with 
the group being both Domain Local and Universal with the same results. There is 
only one member of the group, the user that I am attempting login with.

Have I missed something?

David Eddleman

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: expired certificates - pki-tomcat not running

2017-08-08 Thread Michael Gusek via FreeIPA-users 
Hi Fraser,

at the moment, i can't provide this logfile, i've moved that back to
have only new log lines. But a new new logfile is not created ??? In my
old logfile i have some lines after switch to basic auth, but before
setting time to past:

[07/Aug/2017:14:16:22][localhost-startStop-1]: CMSEngine.shutdown()
[07/Aug/2017:14:21:39][localhost-startStop-1]:

[07/Aug/2017:14:21:39][localhost-startStop-1]: =  DEBUG SUBSYSTEM
INITIALIZED   ===
[07/Aug/2017:14:21:39][localhost-startStop-1]:

[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: about to look
for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: done init id=debug
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initialized debug
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initSubsystem
id=log
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: ready to init
id=log
[07/Aug/2017:14:21:39][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/signedAudit/ca_audit)
[07/Aug/2017:14:21:39][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/system)
[07/Aug/2017:14:21:39][localhost-startStop-1]: Creating
RollingLogFile(/var/lib/pki/pki-tomcat/logs/ca/transactions)
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: about to look
for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: done init id=log
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initialized log
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initSubsystem
id=jss
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: ready to init
id=jss
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: restart at
autoShutdown? false
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: autoShutdown
crumb file path? /var/lib/pki/pki-tomcat/logs/autoShutdown.crumb
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: about to look
for cert for auto-shutdown support:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: found
cert:auditSigningCert cert-pki-ca
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: done init id=jss
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initialized jss
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: initSubsystem
id=dbs
[07/Aug/2017:14:21:39][localhost-startStop-1]: CMSEngine: ready to init
id=dbs
[07/Aug/2017:14:21:39][localhost-startStop-1]: DBSubsystem: init() 
mEnableSerialMgmt=true
[07/Aug/2017:14:21:39][localhost-startStop-1]: Creating
LdapBoundConnFactor(DBSubsystem)
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapBoundConnFactory: init
[07/Aug/2017:14:21:39][localhost-startStop-1]:
LdapBoundConnFactory:doCloning true
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init()
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init begins
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init:
prompt is internaldb
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init: try
getting from memory cache
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init:
password not in memory
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo:
getPasswordFromStore: try to get it from password store
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo:
getPasswordFromStore: about to get from passwored store: internaldb
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo:
getPasswordFromStore: password store available
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo:
getPasswordFromStore: password found for prompt in password store
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: password
ok: store in memory cache
[07/Aug/2017:14:21:39][localhost-startStop-1]: LdapAuthInfo: init ends
[07/Aug/2017:14:21:39][localhost-startStop-1]: init: before
makeConnection errorIfDown is true
[07/Aug/2017:14:21:39][localhost-startStop-1]: makeConnection:
errorIfDown true
[07/Aug/2017:14:21:39][localhost-startStop-1]: Established LDAP
connection using basic authentication to host ipa-prod-01. port
389 as cn=Directory Manager

[Freeipa-users] Re: Creating certificate for master domain

2017-08-08 Thread Rafał Wądołowski via FreeIPA-users 
We have host which is registered and have http service with one domain
e.g. xyz.intra.example.com.

But we want to add another site with domain intra.example.com, and we
need to enroll certificate for that domain, but we can't because the
hostname of these host is xyz.intra.example.com.

Is it possible to force client service with specified domain? and create
certificate for it?

BR,
Rafał

On 03/08/17 16:03, Rob Crittenden via FreeIPA-users wrote:
> Rafał Wądołowski wrote:
>> Okey, but how can I create certificate for domain intra.example.com?
>>
>> I can't create host, because the hostname is required. When I try to add
>> service, I got output that principal is required.
> Like I said, every cert needs to live in a bucket (user, service, etc)
> so since domain can't fit into one, you can't issue a cert for it.
>
> What would it be used for? I'm not sure how meaningful a domain name in
> a cert is, but it could be a use-case we missed.
>
> rob
>
>>
>> Pozdrawiam,
>>
>> Rafał Wądołowski
>>
>> On 02/08/17 15:55, Rob Crittenden via FreeIPA-users wrote:
>>> Rafał Wądołowski via FreeIPA-users wrote:
 Hi,

 I have freeipa 4.4 cluster with CN intra.example.com.

 We developed intranet on this same domain, but I can't create a valid
 certificate for it.

 I can't create service, because hostname is required. Is it other way to
 sign the CSR?

 What is the good practice for creating https certificates?

>>> I don't understand the question.
>>>
>>> A certificate can only be issued for objects that IPA knows about, a
>>> service, host or user.
>>>
>>> rob
>>> ___
>>> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
>>> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Cannot access Web UI after IPA upgrade to 4.5

2017-08-08 Thread Pavel Vomacka via FreeIPA-users 

Hello Gustavo,


On 08/07/2017 04:20 PM, Gustavo Berman via FreeIPA-users wrote:


Hi there,
Today we upgraded to the latest IPA 4.5, log says it upgraded just 
fine, ipa seems to authenticate allright, but web ui fails with:



Operations Error


Some operations failed.


an internal error has occurred


And the details it shows when I press the OK button are:


  Runtime error

Web UI got in unrecoverable state during "profile" phase.


  Technical details:

t.metadata is undefined
|update_logged_in@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:18156 
 
choose_profile@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:16651 
register_phases/ 
<@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:1181 
_run_phase/ 
<@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3476 
 
forEach@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:29752 
 
_run_phase@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3440 
 
next_phase@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3899 
_run_phase/ 
<@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3626 
 
c@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:60960 
d/t.then@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:62246 
 
_run_phase@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3548 
 
next_phase@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3899 
_run_phase/ 
<@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:3626 
 
c@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:60960 
 
l@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:60886 
d/this.resolve@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:61873 
dojo/promise/all/ 
https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:85255 
 
c@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:60960 
 
l@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:60886 
d/this.resolve@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:61873 
register_phases/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:1092 
 
on_success@https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:34431 
freeipa/rpc/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:57160 
freeipa/rpc/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:56953 
freeipa/rpc/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:56790 
freeipa/rpc/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:56340 
freeipa/rpc/ 
https://ipaserver.fisica.cabib/ipa/ui/js/freeipa/app.js?40500:1:53786 
 
f@https://ipaserver.fisica.cabib/ipa/ui/js/dojo/dojo.js?v=40500:1:49586 
dojo/on/

[Freeipa-users] Re: SUDO Rules not getting processed

2017-08-08 Thread Ronald Wimmer via FreeIPA-users 
Are you 100% sure that you have a line like "sudoers: files sss" in your 
/etc/nsswitch.conf?

Am 7. August 2017 11:10:56 MESZ schrieb Alka Murali via FreeIPA-users 
:
>Hello Team,
>
>Have checked all the logs, and the SSSD Logs are saying that it is
>processing the sudo rules which I have configured on my FreeIPA Server.
>However if I run sudo commands on my client, it is giving me the
>message
>that the user is not in sudoers file.
>
>Is it an issue with my SUDO package on Ubuntu or an issue with SSSD.I
>have
>been using the same Configuration in my other clients and all of them
>are
>able to fetch the SUDO Rules.
>
>Please provide me an update on the issue.
>
>Thanks and Regards,
>Alka Murali
>
>On Fri, Aug 4, 2017 at 7:31 PM, Alka Murali 
>wrote:
>
>> Hello,
>>
>> I have implemented a freeipa server and enrolled many clients like
>Ubuntu,
>> Debian, CentOS. In all those clients, my sudo rules worked.
>>
>> However if I try the sudo rules to the users in Ubuntu 16, its not
>> recognising the sudo user
>>
>> --
>>
>> Aug  4 19:22:40  sudo: pam_unix(sudo:auth): authentication
>failure;
>> logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device
>rhost=
>> user=device
>>
>> Aug  4 19:22:40 * sudo: pam_sss(sudo:auth): authentication
>success;
>> logname=device uid=144130 euid=0 tty=/dev/pts/1 ruser=device
>rhost=
>> user=device
>>
>> Aug  4 19:22:40 * sudo:   device : user NOT authorized on host ;
>> TTY=pts/1 ; PWD=/home/device ; USER=root ; COMMAND=/usr/bin/less
>> /var/log/syslog
>>
>> ---
>>
>> I have updated the sssd and ldap configuration file as well as
>nssswitch
>> conf. However the rule was not being accepted.
>>
>> I have properly configured SSSD, LDAP and NSS. Let me know if any
>> additional settings needs to be updated.
>>
>>
>> Awaiting your reply.
>>
>>
>> Thanks and Regards,
>>
>> Alka Murali
>>

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Failed Upgrade?

2017-08-08 Thread thierry bordaz via FreeIPA-users 



On 08/07/2017 09:22 AM, Florence Blanc-Renaud via FreeIPA-users wrote:

On 08/04/2017 11:02 PM, Ian Harding via FreeIPA-users wrote:

On 8/4/17 2:16 AM, Florence Blanc-Renaud wrote:


On 08/03/2017 11:13 PM, Ian Harding via FreeIPA-users wrote:

On 08/03/2017 12:28 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 11:51 PM, Ian Harding via FreeIPA-users wrote:

On 08/02/2017 12:11 AM, Florence Blanc-Renaud wrote:

On 08/02/2017 01:43 AM, Ian Harding wrote:

On 08/01/2017 12:03 PM, Rob Crittenden wrote:

Ian Harding wrote:

On 08/01/2017 07:39 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 03:11 PM, Ian Harding wrote:

On 08/01/2017 01:48 AM, Florence Blanc-Renaud wrote:

On 08/01/2017 01:32 AM, Ian Harding via FreeIPA-users wrote:



On 07/31/2017 11:34 AM, Rob Crittenden wrote:

Ian Harding via FreeIPA-users wrote:
I had an unexpected restart of an IPA server that had 
apparently had
updates run but had not been restarted. ipactl says 
pki-tomcatd

would
not start.

Strangely, the actual service appears to be running:



dogtag is an application within tomcat so tomcat can run 
without

dogtag
running.

We need to see more of the dogtag debug log to see what 
is going on.




It looks like an authentication problem...

[28/Jul/2017:10:08:47][localhost-startStop-1]: SSL 
handshake happened
Could not connect to LDAP server host 
seattlenfs.bpt.rocks port 636
Error netscape.ldap.LDAPException: Authentication failed 
(49)




Hi,

dogtag stores its internal data in the LDAP server and 
needs to

establish a secure LDAP connection. You can check how this
connection is configured in /etc/pki/pki-tomcat/ca/CS.cfg, 
look for

the lines:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=cn=Directory Manager
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert 
cert-pki-ca

internaldb.ldapconn.host=vm-...
internaldb.ldapconn.port=636
internaldb.ldapconn.secureConn

authtype can be SslClientAuth (authentication with a ssl
certificate) or BasicAuth (authentication with a bind DN and
password stored in 
/var/lib/pki/pki-tomcat/conf/password.conf).


You can use this information to manually check the 
credentials. For

instance with sslclientauth:

export LDAPTLS_CACERTDIR=/etc/pki/pki-tomcat/alias
export LDAPTLS_CERT='subsystemCert cert-pki-ca'

ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y 
EXTERNAL
(provide the password from 
/etc/pki/pki-tomcat/alias/pwdfile.txt)




I found this:

internaldb.ldapauth.authtype=SslClientAuth
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipaca
internaldb.ldapauth.bindPWPrompt=internaldb
internaldb.ldapauth.clientCertNickname=subsystemCert 
cert-pki-ca

internaldb.ldapconn.cloneReplicationPort=389
...

and when I try the ldapsearch I am presented with a prompt 
to provide

a pin/password

Please enter pin, password, or pass phrase for security 
token 'ldap(0)':


but there is no password file...


Hi,

you are right, in 4.4. there is no pwdfile.txt and the 
password can be
found in /var/lib/pki/pki-tomcat/conf/password.conf (with 
the tag

internal=...)

Can you check if the password with the tag internal=... 
allows to read

the keys from the NSS db?
certutil -K -d /etc/pki/pki-tomcat/alias
(provide password)


That works...

# certutil -K -d /etc/pki/pki-tomcat/alias
certutil: Checking token "NSS Certificate DB" in slot "NSS 
User Private

Key and Certificate Services"
Enter Password or Pin for "NSS Certificate DB":
< 0> rsa 0f327e760a7eecdcf6973f5dc57ca5367c592d64 (orphan)
< 1> rsa b12580c7c696cfcd8aefc9405a7a870b24b7b96a   NSS 
Certificate

DB:auditSigningCert cert-pki-ca
< 2> rsa 881b7254c40fa40bc50681bcc8d37bb3eb49937e caSigningCert
cert-pki-ca
< 3> rsa fa9a255a1d15585ac28064c0f4986e416bc48403   NSS 
Certificate

DB:ocspSigningCert cert-pki-ca
< 4> rsa 3fb609d0f7d72c2d325d6a2dc16577a7f7e5a01f Server-Cert
cert-pki-ca
< 5> rsa 1e9479a9556af9339bb5e4552ccbd381d3c38856   NSS 
Certificate

DB:subsystemCert cert-pki-ca

But this doesn't (with the same password from password.conf)

# ldapsearch -H ldaps://`hostname`:636 -b "" -s base -Y EXTERNAL
Please enter pin, password, or pass phrase for security token 
'ldap(0)':

SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)

That password is getting me somewhere though, since if I put 
in a

nonsense or incorrect password it just prompts over and over.


Let's step back a second. You upgraded from what to what?


There wasn't much of a change... I just assumed someone ran yum 
upgrade and didn't restart, then the power outage... it looks 
like not much of a version change though.


# grep ipa /var/log/yum.log
Jan 08 04:45:32 Installed: 
ipa-common-4.4.0-14.el7.centos.1.1.noarch
Jan 08 04:45:32 Installed: 
ipa-client-common-4.4.0-14.el7.centos.1.1.noarch

Jan 08 04:46:06 Updated: libipa_hbac-1.14.0-43.el7_3.4.x86_64
Jan 08 04:46:07 Updated: 
python-libipa_hbac-1.14.0-43.el7_3.4.x86_64

Jan 08 04:46:08 Installed:

[Freeipa-users] Re: Chrome 58 Doesn't Trust SSL Certificates Signed by FreeIPA

2017-08-08 Thread Prasun Gera via FreeIPA-users 
I think this has resolved itself on its own after the update to RHEL 7.4.
So that was a pleasant surprise.

On Wed, Aug 2, 2017 at 8:53 AM, Prasun Gera  wrote:

> I think the path that is triggered first is from the following code:
>
> if new_cert == old_cert:
>
> syslog.syslog(syslog.LOG_INFO, "Updated certificate not
> available")
> # No cert available yet, tell certmonger to wait another 8 hours
>
> return (WAIT_WITH_DELAY, 8 * 60 * 60, '')
>
> This causes the status to change to CA_WORKING for a while. Later, the
> status changes to the cookie error. The old cert is still valid. So is it
> supposed to get a new cert ?
>
> On Mon, Jul 31, 2017 at 2:51 PM, Prasun Gera 
> wrote:
>
>> They are published, or at least it would seem that way. These were my
>> queries:
>> ldapsearch -h ipa_master -x -D 'cn=directory manager' -b
>> cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
>> ldapsearch -h ipa_replica -x -D 'cn=directory manager' -b
>> cn="subsystemCert cert-pki-ca",cn=ca_renewal,cn=ipa,cn=etc,dc= -W
>> On master: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
>> "subsystemCert cert-pki-ca" -a
>> On replica: sudo certutil -L -d /etc/pki/pki-tomcat/alias -n
>> "subsystemCert cert-pki-ca" -a
>>
>> They all return the same cert.
>>
>> Also, there was another thread on the mailing list with similar symptoms.
>> I'm not sure if there was a resolution.
>> https://www.redhat.com/archives/freeipa-users/2017-January/msg00111.html
>>
>>
>>
>> On Mon, Jul 31, 2017 at 2:40 PM, Rob Crittenden 
>> wrote:
>>
>>> Prasun Gera via FreeIPA-users wrote:
>>> > The entry is present on both master, and replica. Also, the status on
>>> > replica for those two has changed to *'ca-error: Invalid cookie: '''*.
>>> > The certs listed by certutil on both systems, as well as the ones
>>> listed
>>> > by the ldap query seem to match. When I try to resubmit, there is also
>>> > this message in the system log "dogtag-ipa-ca-renew-agent-submit:
>>> > Updated certificate not available". Any way to run some diagnostics on
>>> > the newly added dogtag-ipa-ca-renew-agent on the replica ?
>>>
>>> Did you follow Flo's previous advice and look in LDAP to see if the
>>> updated certificates were published? It would seem that they were not.
>>>
>>> rob
>>>
>>> >
>>> > On Thu, Jul 27, 2017 at 9:30 AM, Florence Blanc-Renaud >> > > wrote:
>>> >
>>> > On 07/27/2017 02:39 PM, Prasun Gera via FreeIPA-users wrote:
>>> >
>>> > Sorry about this rather long thread, and I appreciate all the
>>> > help. After adding the new ca, the new tracking requests show
>>> > the status as "CA_WORKING" instead of "MONITORING".
>>> >
>>> > For example, the replica shows this for one of the requests:
>>> > Request ID '20170727122353':
>>> > status: CA_WORKING
>>> > stuck: no
>>> > key pair storage:
>>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>>> caSigningCert
>>> > cert-pki-ca',token='NSS Certificate DB',pin set
>>> > certificate:
>>> > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='
>>> caSigningCert
>>> > cert-pki-ca',token='NSS Certificate DB'
>>> > CA: dogtag-ipa-ca-renew-agent
>>> > issuer: CN=Certificate Authority,O=ORG.EDU 
>>> > 
>>> > subject: CN=Certificate Authority,O=ORG.EDU 
>>> > 
>>> > expires: 2035-04-08 17:34:47 UTC
>>> > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
>>> > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
>>> > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
>>> > "caSigningCert cert-pki-ca"
>>> > track: yes
>>> > auto-renew: yes
>>> >
>>> > Same status for subsystemCert cert-pki-ca. However, ipaCert
>>> > shows monitoring, which is also tracked by
>>> > dogtag-ipa-ca-renew-agent. There are still a few more left that
>>> > I need to add. Is this status normal ?
>>> >
>>> >
>>> > On Mon, Jul 24, 2017 at 6:19 AM, Florence Blanc-Renaud
>>> >  >> > >> wrote:
>>> >
>>> > On 07/23/2017 01:29 AM, Prasun Gera via FreeIPA-users
>>> wrote:
>>> >
>>> > I tried to replicate every one of those on the replica,
>>> > but I've
>>> > hit a
>>> > snag. The following CA only exists on the master, but
>>> > not on the
>>> > replica:
>>> >
>>> > CA 'dogtag-ipa-ca-renew-agent':
>>> > is-default: no
>>> > ca-type: EXTERNAL
>>> > helper-location:
>>> >

[Freeipa-users] Re: Extended Schema attributes missing

2017-08-08 Thread Kristian Petersen via FreeIPA-users 
Great, thanks!

On Aug 4, 2017 11:58 PM, "Alexander Bokovoy"  wrote:

> On pe, 04 elo 2017, Kristian Petersen via FreeIPA-users wrote:
>
>> Alexander,
>>
>> That was it!  I had seen this before at a previous place of employment,
>> but
>> couldn't recall enough of what we'd done there to fix it.  You're a
>> lifesaver, really. Thank you very much to *everyone* who chimed in to lend
>> a hand.
>>
>> PS: We're still running FreeIPA 4.4.0 and were affected by this change
>> that
>> occurred in where the plugins files get stored.  That may be something to
>> pass on to others.
>>
> You are right, a split in plugins for server and client side happened
> during 4.4 release:
> $ git tag --contains 6e44557b601f769d23ee74555a72e8b5cc62c0c9
> alpha_1-4-4-0
> release-4-4-0
> release-4-4-1
> release-4-4-2
> release-4-4-3
> release-4-4-4
> release-4-5-0
> release-4-5-1
> release-4-5-2
> release-4-5-3
>
> $ git show -s  6e44557b601f769d23ee74555a72e8b5cc62c0c9
> commit 6e44557b601f769d23ee74555a72e8b5cc62c0c9
> Author: Jan Cholasta 
> Date:   Thu Apr 28 10:30:05 2016 +0200
>
>ipalib: move server-side plugins to ipaserver
>   Move the remaining plugin code from ipalib.plugins to
> ipaserver.plugins.
>   Remove the now unused ipalib.plugins package.
>   https://fedorahosted.org/freeipa/ticket/4739
>   Reviewed-By: David Kupka 
>
>
> It is more complex than that, you can see
> https://pagure.io/freeipa/issue/4739 for a history of commits that went
> in to implement the split.
>
> I think I need to rewrite my plugin guide but one can use
> https://github.com/abbra/freeipa-desktop-profile/ now as an example how
> both client and server side plugins should look like these days. It also
> shows how to integrate well new LDAP schema definitions with FreeIPA
> server upgrade code.
>
>
>> On Fri, Aug 4, 2017 at 9:41 AM, Alexander Bokovoy 
>> wrote:
>>
>> On pe, 04 elo 2017, Kristian Petersen wrote:
>>>
>>> If it helps, the python file where we customized things is included
 below:

 # Place in /usr/lib/python2.7/site-packages/ipalib/plugins/

 Ok, this is location for pre-4.5 plugins. With FreeIPA 4.5 we split them
>>> into ipaserver/plugins and ipaclient/plugins, to allow clear separation
>>> between server and client side plugins and to make thin client operation
>>> possible.
>>>
>>> Move your plugin Python code to ipaserver/plugins/ subdirectory instead
>>> of ipalib/plugins. Also replace 'from ipalib.plugins' by 'from
>>> ipaserver.plugins ..'.
>>>
>>>
>>>
>>>
>>> import re

 from ipalib import api
 from ipalib.plugins import user, stageuser, group
 from ipalib.parameters import Str
 from ipalib import _


 FILESERVER = "fileserver.chem.byu.edu"
 GIDS = [
("csr",'1000'),
("staff",  '3000'),
("faculty",'4000'),
("adjunct",'4010'),
("visiting",   '4020'),
("emeritus",   '4100'),
("graduate",   '5000'),
("researcher", '6000'),
("ugrad",  '8000'),
]
 GROUP_TO_GID = {x: y for x, y in GIDS}
 GID_TO_GROUP = {y: x for x, y in GIDS}
 # Locations of home directories for different groups.
 HOME_DIR_LOCATION = {
 '1000':  "/home/csr", # csr
 '3000':  "/home/staff", # staff
 '4000':  "/home/faculty",   # faculty
 '4010':  "/home/faculty",   # adjunct
 '4020':  "/home/postdoc",   # visiting
 '4100':  "/home/faculty",   # emeritus
 '5000':  "/home/research",  # graduate
 '6000':  "/home/research",  # researcher
 '8000':  "/home/students",  # ugrad
 }


 
 # Expose attributes to CLI #
 
 def __check_netid(ugettext, netid):
'''
Checks if netid is already assigned to an existing account.
'''

# Search for users with given NetID
result = api.Command.user_find(netid=netid)

# Throw error if NetID is already assigned to a user account
if result['count'] > 0:
uid = result['result'][0]['uid'][0]
return _("NetID is already assigned to user \"{}\".".format(uid))


 def __validate_student_id(ugettext, studentid):
'''
Checks if studentid string is all numbers and nine digits long.
Also checks if studentid is already assigned to an existing account.
'''

if not (studentid.isdigit() and len(studentid) == 9):
return _("Student ID must be 9 digits")

# Check if ID number is already assigned to another account
result =

[Freeipa-users] remove ipa-dns-server ?

2017-08-08 Thread Günther J . Niederwimmer via FreeIPA-users 
Hello,
CentOS 7.3
what is the best way to remove a installed ipa-dns-server?

I can't found any helpful Doc's for this only for installing the server I 
found Docs

Thanks for the Help, 
-- 
mit freundlichen Grüssen / best regards,

  Günther J. Niederwimmer
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Using AWS ELB with 2 FreeIPA servers

2017-08-08 Thread Bob Rentschler via FreeIPA-users 
You may be over complicating things by using a load balancer, IPA does a
fairly good job of balancing things
itself, for example the default SSSD config is to have this:

ipa_server = _srv_, 

meaning it will select which host to communicate with via the DNS service
records, which are automatically
created. You can refine the server selection by setting up locations if
desired. This naturally is not perfect
but does have the additional advantage of being maintained by IPA. Adding a
third server updates everything
for you so you don't have to reconfigure a load balancer.

In short do away with the load balancer, you shouldn't need it.

Bob

On Tue, Aug 8, 2017 at 9:06 AM, ridha.zorgui--- via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> I set up a FreeIPA master and replica behind an elastic load balancer in
> AWS cloud. FreeIPA Clients will be contacting the replica and the master
> sever through the load balancer so the dns name used when configurting the
> clients is the ELB CNAME. The problem is when retreiving ldap data and
> during the authentication, the SSL handshake fails as the certificate sent
> back from the master or replica has a hostname different than the one used
> in the sssd ( the ELB CNAME). so the connection is terminated.  There is a
> workaround which is the use reqcert=allow but this bring a security issue
> with a MITM attack. another solution i found is the use SAN. I was able to
> add the ELB DNS as a SAN in freeipa servers certificate. i made sure it is
> there by downloading the certificate and checking that the elb san exist
> but when testing it the same problem remain. Please help.
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] FIPA OTP 2FA

2017-08-08 Thread saidireddy ranabothu via FreeIPA-users 
Hello all,

I have enabled password+OTP authentication for a user and able to sync
tokens and SSH.

While ssh to server using FIPA credentials it's asking authentication in
two steps as First Factor and Second Factor .

But i just want to give it in a single line password ,Can any one suggest
how to do it as  a single line password?

-- 
Thanks,
SaidiReddy
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: howto replace an externally signed CA

2017-08-08 Thread Harald Dunkel via FreeIPA-users 
Hi Flo,

On Wed, 2 Aug 2017 16:24:00 +0200
Florence Blanc-Renaud  wrote:

> Hi,
> 
> You can follow the steps described here: 
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cert-renewal.html#manual-cert-renewal-ext
> 
> ipa-cacert-manage renew --external-ca will create a CSR file that can be 
> sent to the new certificate authority. You will then receive a new cert 
> for IPA + a new CA chain that will be used in ipa-cacert-manage renew 
> --external-cert-file.
> 
> HTH,
> Flo

This appears to be a very precise documentation, but if you look 
closely then you get


# ssh root@ipaclient1
# ipa-certupdate 
trying https://ipa2.example.com/ipa/json
Forwarding 'schema' to json server 'https://ipa2.example.com/ipa/json'
trying https://ipa2.example.com/ipa/json
Forwarding 'ca_is_enabled' to json server 'https://ipa2.example.com/ipa/json'
Forwarding 'ca_find/1' to json server 'https://ipa2.example.com/ipa/json'
Systemwide CA database updated.
The ipa-certupdate command was successful

# certutil -L -d /etc/pki/pki-tomcat/alias/
certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key 
database is in an old, unsupported format.


This is *before* I installed the new certificate. I get this with
freeipa 4.4.0 on CentOS 7.3 and 4.4.4 on Debian.

Doesn't look very reliable, does it? Thats my concern. Not to 
mention that /etc/pki/pki-tomcat/alias doesn't even exist, so 
I wonder what did ipa-certupdate do?

???


Every helpful comment is highly appreciated.
Harri
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Cannot access Web UI after IPA upgrade to 4.5

2017-08-08 Thread Gustavo Berman via FreeIPA-users 
Pavel,
Thanks for the help, that solved the problem. Now I can access the web ui.
The upgrade took place yesterday and it was a release upgrade from rhel 7.3
(last update was last week) to rhel 7.4 (so we had a lot of package
updates):

ID | Command line | Date and time| Action(s)  |
Altered
---
35 | update   | 2017-08-07 09:07 | E, I, O, U |
470 EE


Acording to yum history info, this are the ipa packages that where updated:
Obsoleted
ipa-admintools-4.4.0-14.el7_3.7.noarch@rhel7
Updated
ipa-client-4.4.0-14.el7_3.7.x86_64@rhel7
Obsoleting
ipa-client-4.5.0-21.el7.x86_64@rhel7
Updated
ipa-client-common-4.4.0-14.el7_3.7.noarch @rhel7
Update
4.5.0-21.el7.noarch @rhel7
Updated
ipa-common-4.4.0-14.el7_3.7.noarch@rhel7
Update
4.5.0-21.el7.noarch@rhel7
Updated
ipa-python-compat-4.4.0-14.el7_3.7.noarch @rhel7
Update
4.5.0-21.el7.noarch @rhel7
Updated
ipa-server-4.4.0-14.el7_3.7.x86_64@rhel7
Update
4.5.0-21.el7.x86_64@rhel7
Updated
ipa-server-common-4.4.0-14.el7_3.7.noarch @rhel7
Update
4.5.0-21.el7.noarch @rhel7
Updated
ipa-server-dns-4.4.0-14.el7_3.7.noarch@rhel7
Update
4.5.0-21.el7.noarch@rhel7
Updated
libipa_hbac-1.14.0-43.el7_3.18.x86_64 @rhel7
Update
1.15.2-50.el7.x86_64  @rhel7
Updated
python-libipa_hbac-1.14.0-43.el7_3.18.x86_64  @rhel7
Update
1.15.2-50.el7.x86_64   @rhel7
Updated
python2-ipaclient-4.4.0-14.el7_3.7.noarch @rhel7
Update
4.5.0-21.el7.noarch @rhel7
Updated
python2-ipalib-4.4.0-14.el7_3.7.noarch@rhel7
Update
4.5.0-21.el7.noarch@rhel7
Updated
python2-ipaserver-4.4.0-14.el7_3.7.noarch @rhel7
Update
4.5.0-21.el7.noarch @rhel7
Updated
sssd-ipa-1.14.0-43.el7_3.18.x86_64@rhel7
Update
1.15.2-50.el7.x86_64 @rhel7


Again, thanks for the help!
Kind regards


On Tue, Aug 8, 2017 at 5:51 AM, Pavel Vomacka  wrote:

>
>
> On 08/07/2017 07:01 PM, Gustavo Berman via FreeIPA-users wrote:
>
> Hello Pavel
>
> On Mon, Aug 7, 2017 at 12:40 PM, Pavel Vomacka 
> wrote:
>
>>
>> Hello Gustavo,
>> From what I can see, the issue would be PROTOCOL ERROR in whoami command.
>> Could you please check whether all services running? Please run
>> # ipactl status
>>
>> and post the output.
>>
>>
> # ipactl status
> Directory Service: RUNNING
> krb5kdc Service: RUNNING
> kadmin Service: RUNNING
> named Service: RUNNING
> httpd Service: RUNNING
> ipa-custodia Service: RUNNING
> pki-tomcatd Service: RUNNING
> ipa-otpd Service: RUNNING
> ipa-dnskeysyncd Service: RUNNING
> ipa: INFO: The ipactl command was successful
>
>
>
>
>> And please could you send me the /etc/named.conf? Especially everything
>> after
>>  dyndb "ipa"
>> line is interesting for us.
>>
>
> This is from /etc/named.conf
>
> options {
> // turns on IPv6 for port 53, IPv4 is on by default for all ifaces
> listen-on-v6 {any;};
>
> // Put files that named is allowed to write in the data/ directory:
> directory "/var/named"; // the default
> dump-file   "data/cache_dump.db";
> statistics-file "data/named_stats.txt";
> memstatistics-file  "data/named_mem_stats.txt";
>
> forward only;
> forwarders {
> 10.73.2.100;
> 10.73.2.102;
> 10.73.2.101;
> };
>
> // Any host is permitted to issue recursive queries
> allow-recursion { any; };
>
> tkey-gssapi-keytab "/etc/named.keytab";
> pid-file "/run/named/named.pid";
> dnssec-enable yes;
> dnssec-validation no;
> bindkeys-file "/etc/named.iscdlv.key";
> managed-keys-directory "/var/named/dynamic";
> };
>
> /* If you want to enable debugging, eg. using the 'rndc trace' command,
>  * By default, SELinux policy does not allow named to modify the
> /var/named directory,
>  * so put the default debug log file in data/ :
>  */
> logging {
> channel default_debug {
> file "data/named.run";
> severity dynamic;
> print-time yes;
> };
> };
>
> zone "." IN {
> type hint;
> file "named.ca";
> };
>
> include

[Freeipa-users] expired certificates - pki-tomcat not running

2017-08-08 Thread Michael Gusek via FreeIPA-users 
Hello,

we run in a problem with expired certificates:

> getcert list (sample show only one expired certificate)
...
Request ID '20170202144747':
  status: MONITORING
  stuck: no
  key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
  certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS
Certificate DB'
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  subject: CN=IPA RA,O=NBG.WEBTREKK.COM
  expires: 2017-07-30 13:37:02 UTC
  key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
  eku: id-kp-serverAuth,id-kp-clientAuth
  pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
  post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
  track: yes
  auto-renew: yes

...
Request ID '20170202144746':
  status: MONITORING
  stuck: no
  key pair storage:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB',pin set
  certificate:
type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert
cert-pki-ca',token='NSS Certificate DB'
  CA: dogtag-ipa-ca-renew-agent
  issuer: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  subject: CN=Certificate Authority,O=NBG.WEBTREKK.COM
  expires: 2035-08-10 13:36:23 UTC
  key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign
  pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad
  post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert
"caSigningCert cert-pki-ca"
  track: yes
  auto-renew: yes
...

We follow instruction to renew certificates found on this mailing list:
* set system time before expired
* set dogtag to use simple binds instead of TLS to connect to LDAP
* ipactl start --ignore-service-failures
* systemctl restart pki-tomcatd@pki-tomcat
* systemctl restart certmonger
* resubmit one of expired certificate: ipa-getcert resubmit -i
20170202144747

Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-ca-renew-agent-submit[10651]: Forwarding request to
dogtag-ipa-renew-agent  
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-renew-agent-submit[10661]: GET http://ipa-prod-01.:8080/
ca/ee/ca/profileSubmit?profileId=caServerCert_num=7=true=true
  
 
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-renew-agent-submit[10661]: Apache
Tomcat/7.0.69 -
or report HTTP Status 404 - /ca/ee/ca/profileSubmittype Status reportmessage
 /ca/ee/ca/profileSubmitdescription The
requested resource is not available.Apache
Tomcat/7.0.69

 
Jul 29 13:27:05 ipa-prod-01.
dogtag-ipa-ca-renew-agent-submit[10651]: dogtag-ipa-renew-agent returned 2  


In certmonger logs, we can see that the request is forwarded to
dogtag-ipa-renew-agent, but agent returned with return code 2, which
seemed to be "request rejected". So at this point I have no glue to
solve this problem. Any help is desired.

> ipa
--version   
  
 
VERSION: 4.4.0, API_VERSION: 2.213  

Many thanks

Michael
-- 




*Michael**Gusek*| System Administrator| Webtrekk GmbH |
*t*+49 30 755 415 302| *f *+49 30 755 415 100 | *w *www.webtrekk.com

Amtsgericht/Local Court Berlin, HRB 93435 B | Geschäftsführer/CEO
Christian Sauer


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Cannot access Web UI after IPA upgrade to 4.5

2017-08-08 Thread Pavel Vomacka via FreeIPA-users 



On 08/07/2017 07:01 PM, Gustavo Berman via FreeIPA-users wrote:

Hello Pavel

On Mon, Aug 7, 2017 at 12:40 PM, Pavel Vomacka > wrote:



Hello Gustavo,

From what I can see, the issue would be PROTOCOL ERROR in whoami
command. Could you please check whether all services running?
Please run
# ipactl status

and post the output.


# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
ipa-custodia Service: RUNNING
pki-tomcatd Service: RUNNING
ipa-otpd Service: RUNNING
ipa-dnskeysyncd Service: RUNNING
ipa: INFO: The ipactl command was successful


And please could you send me the /etc/named.conf? Especially
everything after
 dyndb "ipa"
line is interesting for us.


This is from /etc/named.conf

options {
// turns on IPv6 for port 53, IPv4 is on by default for all ifaces
listen-on-v6 {any;};

// Put files that named is allowed to write in the data/ 
directory:

directory "/var/named"; // the default
dump-file   "data/cache_dump.db";
statistics-file "data/named_stats.txt";
memstatistics-file "data/named_mem_stats.txt";

forward only;
forwarders {
10.73.2.100;
10.73.2.102;
10.73.2.101;
};

// Any host is permitted to issue recursive queries
allow-recursion { any; };

tkey-gssapi-keytab "/etc/named.keytab";
pid-file "/run/named/named.pid";
dnssec-enable yes;
dnssec-validation no;
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
};

/* If you want to enable debugging, eg. using the 'rndc trace' command,
 * By default, SELinux policy does not allow named to modify the 
/var/named directory,

 * so put the default debug log file in data/ :
 */
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
print-time yes;
};
};

zone "." IN {
type hint;
file "named.ca ";
};

include "/etc/named.rfc1912.zones";

dyndb "ipa" "/usr/lib64/bind/ldap.so" {
uri "ldapi://%2fvar%2frun%2fslapd-FISICA-CABIB.socket";
base "cn=dns, dc=fisica,dc=cabib";
fake_mname "ipaserver.fisica.cabib.";
auth_method "sasl";
sasl_mech "GSSAPI";
sasl_user "DNS/ipaserver.fisica.cabib";
server_id "ipaserver.fisica.cabib";
};
include "/etc/named.root.key";

key "rndc-key" {
algorithm hmac-md5;
secret "#";
};



Thank you for the configuration. It looks good.

Another thing that might be incorrect is that the whoami plugin is not 
loaded. Please check whether you have following line:

dn: cn=whoami,cn=plugins,cn=config

in the /etc/dirsrv/slapd-IPASERVER-FISICA-CABIB/dse.ldif

If not please add there following lines (between double quotes and 
without them):


"
dn: cn=whoami,cn=plugins,cn=config
cn: whoami
nsslapd-plugin-depends-on-type: database
nsslapd-pluginDescription: whoami extended operation plugin
nsslapd-pluginEnabled: on
nsslapd-pluginId: whoami-plugin
nsslapd-pluginInitfunc: whoami_init
nsslapd-pluginPath: libwhoami-plugin
nsslapd-pluginType: extendedop
nsslapd-pluginVendor: 389 Project
nsslapd-pluginVersion: 1.3.5.18
objectClass: top
objectClass: nsSlapdPlugin
objectClass: extensibleObject
"

and change the nsslapd-pluginVersion value to the same as other plugins 
have.


Then you will probably need to restart ipa service or at least dirsrv.

Did that help?

Could you please tell us more about upgrade? Especially from which 
version did you upgrade to 4.5 and which OS do you use? Which version of 
IPA did you have when you started using IPA?


--
Gustavo Berman
Sysadmin - Gerencia de Física - Centro Atómico Bariloche - CNEA


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


--
Pavel^3 Vomacka

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org