Re: [Freeipa-users] How to disable First time password change on IPA user

[David Kupka]

On 13/12/16 13:44, Ben .T.George wrote:

HI

How to disable first time password change on newly created user from web UI

Regards,
Ben




Hi Ben,
AFAIK this is not possible to do using the API.

One hacky way I can think of is modifying the krbPasswordExpiration 
attribute in the 389ds after creation of the user.


$ sudo ldapmodify -D "cn=Directory Manager" -w Secret123 -h $HOSTNAME << 
END_LDIF

dn: uid=tuser,cn=users,cn=accounts,dc=example,dc=com
changetype: modify
replace: krbPasswordExpiration
krbPasswordExpiration: $(date -u -d "@$(($(date +'%s')+(90*24*3600)))" 
+'%Y%m%d%H%M%S'Z)

END_LDIF

It works but I would not recommend using it in production environment.

--
David Kupka

--
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] ACIerrors is httpd log

[Jim Richard]

just now getting back to this, have been truncating httpd logs via cron since 
then to keep from filing up my disk.

So, does this ring any bells :)

[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: IPA: virtual verify retrieve 
certificate
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Not granted by ACI to retrieve 
certificate, looking at principal
[Wed Dec 14 00:38:39 2016] [error] ipa: INFO: 
host/phoenix-168.nym1.placeiq@placeiq.net: 
cert_request(u'MIID4zCCAssCAQAwPTEUMBIGA1UEChMLUExBQ0VJUS5ORVQxJTAjBgNVBAMTHHBob2VuaXgtMTY4Lm55bTEucGxhY2VpcS5uZXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDboyDDyTaP4+LxYThfy1w7C67TN2qBp8JjA7Y55gnthyUp/PUUXmm3FUQ4yG4cBqDSxZcUWzl+eA33/ceSIp0HtVl34ZkkUitY1hmUvu2nh16ReR65YC+qRqkAIypOilLdPzXIWZ7u5LbM/Xpj3/Npzm18UupAAznNXkZnojuPmAQ+ulPGypyefLnhr5my6hIaR1atTm1ZvHTG3raMJOJhFe4jMeI/tgPVdNCUfOUdEKhmmCm5KivxhTtHMEcH+8obuQnbaSokJscxlzHBLiyQGqhAn5gznXg0mlVCC0H4mwdB1g2g9cG+SxSua/7XCm+AnGXlc75MZAt594QBTc3fAgMBAAGgggFfMHsGCSqGSIb3DQEJFDFuHmwASQBQAEEAIABNAGEAYwBoAGkAbgBlACAAQwBlAHIAdABpAGYAaQBjAGEAdABlACAALQAgAHAAaABvAGUAbgBpAHgALQAxADYAOAAuAG4AeQBtADEALgBwAGwAYQBjAGUAaQBxAC4AbgBlAHQwgd8GCSqGSIb3DQEJDjGB0TCBzjCBmwYDVR0RAQEABIGQMIGNoD0GCisGAQQBgjcUAgOgLwwtaG9zdC9waG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0QFBMQUNFSVEuTkVUoEwGBisGAQUCAqBCMECgDRsLUExBQ0VJUS5ORVShLzAtoAMCAQGhJjAkGwRob3N0GxxwaG9lbml4LTE2OC5ueW0xLnBsYWNlaXEubmV0MAwGA1UdEwEB/wQCMAAwIAYDVR0OAQEABBYEFKDhj0rZ6mZwJfrJx3pCI12dct5WMA0GCSqGSIb3DQEBCwUAA4IBAQC/zeFtiiiJXi9bws2NWx2u/vB7aTVRci2yb9wb70dUzcpeJ3qRTqsE5I+D3MHxLYnixrG4iMEaWgEyuJy4SIWqW1YVSrHwhJZufyRnxy7luNXON+TBBBI0Gro5gICy9XiDKbA/q6clYzEbwDLe6Es/U5/h4Bl/ziV61KYCJN0P1bMWI21A73iP3EQHx2lefYxI8BJN68hJLQiK+E0IWGCqfvipTHA0bHYSQy6WFmmS96v0wr93jy783iromycZeXWzFJyx+LruVPmPOewmUOJ2Y2NJNPJv35pPYUw5Dt2hlLgWZ18po8C+XYqvMbzxM2DFlxMX3Ff+ZiwCRYSGknFI',
 principal=u'host/phoenix-168.nym1.placeiq@placeiq.net', add=True): ACIError
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: response: ACIError: Insufficient 
access: Gettext('not allowed to perform this command', domain='ipa', 
localedir=None)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: no session id in request, 
generating empty session data with id=9beb89831ebfca453453ad48feaaa4d0
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: 
session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 
access_timestamp=2016-12-14T00:38:39 expiration_timestamp=1970-01-01T00:00:00
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: finalize_kerberos_acquisition: 
xmlserver ccache_name="FILE:/tmp/krb5cc_apache_SQg9kf" 
session_id="9beb89831ebfca453453ad48feaaa4d0"
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: reading ccache data from file 
"/tmp/krb5cc_apache_SQg9kf"
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: get_credential_times: 
principal=krbtgt/placeiq@placeiq.net, authtime=12/14/16 00:38:36, 
starttime=12/14/16 00:38:37, endtime=12/15/16 00:38:36, renew_till=01/01/70 
00:00:00
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: KRB5_CCache 
FILE:/tmp/krb5cc_apache_SQg9kf endtime=1481762316 (12/15/16 00:38:36)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: set_session_expiration_time: 
duration_type=inactivity_timeout duration=1200 max_age=1481762016 
expiration=1481677119.46 (2016-12-14T00:58:39)
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: store session: 
session_id=9beb89831ebfca453453ad48feaaa4d0 start_timestamp=2016-12-14T00:38:39 
access_timestamp=2016-12-14T00:38:39 expiration_timestamp=2016-12-14T00:58:39
[Wed Dec 14 00:38:39 2016] [error] ipa: DEBUG: Destroyed connection 
context.ldap2




     
Jim Richard    
    
    

SYSTEM ADMINISTRATOR III
(646) 338-8905  

 




> On Dec 2, 2016, at 5:29 PM, Rob Crittenden  wrote:
> 
> Jim Richard wrote:
>> Hmm ya. So before I rebuilt anything I thought maybe it was my DNS
>> records but it looks like that’s not it.
>> 
>> More background, I used to have sso-109 and sso-110, both CA’s. I
>> rebuilt sso-110 without CA.
>> 
>> My DNS is external, BIND on another host.
>> 
>> Using the following (at the end of the message) host/key issue as an
>> example. On this host, in sssd.conf, ipa_server and krb5_server values
>> are both _srv_ so that means they’ll discover from DNS right?
>> 
>> But in my krb5.conf I have:
>> 
>> [realms]
>>  PLACEIQ.NET  = {
>>kdc = sso-110.nym1.placeiq.net :88
>>master_kdc = sso-110.nym1.placeiq.net
>> :88
>>admin_server = sso-110.nym1.placeiq.net
>> :749
>>default_domain = placeiq.net 
>>

Re: [Freeipa-users] DNS search timeouts and incomplete results

[Martin Basti]

Receiving huge list of entries is not a cheap operation, that's why 
there is a default max limit set to 100/2000 entries. You have to count 
with that. Maybe direct AXFR from DNS may be more suitable for you, to 
get the complete list of DNS records per zone. But if you are fine with 
speed, memory and CPU consumption on server side, there is no issue why 
dnsrecord-find shouldn't be used.


Martin


On 13.12.2016 17:47, Mike Driscoll wrote:

Thanks Martin.  That is the cause...

$ ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit
Enter LDAP Password:
nsslapd-sizelimit: 2000

This command results in a similar problem that only 100 of 270 record names 
were returned.
$  ipa dnsrecord-find mydomain.com qa

If I specify these limits, I get all 270 records as expected.
$  ipa dnsrecord-find mydomain.com qa --sizelimit=1 --timelimit=20

I have the impression this default size limit meets most needs.  Is my approach 
wrong when wanting to dump the entire DNS list of records via ipa 
dnsrecord-find?

Mike



On Dec 13, 2016, at 08:17, Martin Basti  wrote:

Tomas already replied to you, copying here as archives are currently offline to 
prevent spam

"""

Hi,

you seem to be hitting the size limit on LDAP side. To verify, check

ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit

If you really need to increase this size limit, you will have to modify the 
nsslapd-sizelimit in cn=config.

"""

Martin


On 13.12.2016 17:06, Mike Driscoll wrote:

Any thoughts about this sizelimit bug?

Mike




On Nov 28, 2016, at 14:44, Mike Driscoll  wrote:

I'm running:
# rpm -qa | grep ipa-server
ipa-server-4.4.0-12.0.1.el7.x86_64
ipa-server-dns-4.4.0-12.0.1.el7.noarch
ipa-server-common-4.4.0-12.0.1.el7.noarch

Searching DNS for all hostnames containing "qa" times out in the GUI.  Setting 
aside the option to change server defaults, this cli command isn't giving me the content 
I need:

# ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
ipa: WARNING: Search result has been truncated: Configured size limit exceeded

It seems like the sizelimit parameter greater than two thousand is being 
ignored:

# ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
...
---
Number of entries returned 1900
---

# ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
...
---
Number of entries returned 2000
---

Any suggestions?

Mike


--
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] DNS search timeouts and incomplete results

[Mike Driscoll]

Thanks Martin.  That is the cause...

$ ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit
Enter LDAP Password: 
nsslapd-sizelimit: 2000

This command results in a similar problem that only 100 of 270 record names 
were returned.
$  ipa dnsrecord-find mydomain.com qa

If I specify these limits, I get all 270 records as expected.
$  ipa dnsrecord-find mydomain.com qa --sizelimit=1 --timelimit=20

I have the impression this default size limit meets most needs.  Is my approach 
wrong when wanting to dump the entire DNS list of records via ipa 
dnsrecord-find?

Mike


> On Dec 13, 2016, at 08:17, Martin Basti  wrote:
> 
> Tomas already replied to you, copying here as archives are currently offline 
> to prevent spam
> 
> """
> 
> Hi,
> 
> you seem to be hitting the size limit on LDAP side. To verify, check
> 
> ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
> nsslapd-sizelimit
> 
> If you really need to increase this size limit, you will have to modify the 
> nsslapd-sizelimit in cn=config.
> 
> """
> 
> Martin
> 
> 
> On 13.12.2016 17:06, Mike Driscoll wrote:
>> Any thoughts about this sizelimit bug?
>> 
>> Mike
>> 
>> 
>> 
>>> On Nov 28, 2016, at 14:44, Mike Driscoll  wrote:
>>> 
>>> I'm running:
>>> # rpm -qa | grep ipa-server
>>> ipa-server-4.4.0-12.0.1.el7.x86_64
>>> ipa-server-dns-4.4.0-12.0.1.el7.noarch
>>> ipa-server-common-4.4.0-12.0.1.el7.noarch
>>> 
>>> Searching DNS for all hostnames containing "qa" times out in the GUI.  
>>> Setting aside the option to change server defaults, this cli command isn't 
>>> giving me the content I need:
>>> 
>>> # ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
>>> ipa: WARNING: Search result has been truncated: Configured size limit 
>>> exceeded
>>> 
>>> It seems like the sizelimit parameter greater than two thousand is being 
>>> ignored:
>>> 
>>> # ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
>>> ...
>>> ---
>>> Number of entries returned 1900
>>> ---
>>> 
>>> # ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
>>> ...
>>> ---
>>> Number of entries returned 2000
>>> ---
>>> 
>>> Any suggestions?
>>> 
>>> Mike
>> 
> 


-- 
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] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[jay]

Well Flo, the issue was IPV6 was disabled.  As soon as I enabled it again,
added that /etc/hosts entry back, and rebooted the server, things are
working again!

So is that now a requirement for 4.4.x?  Server worked fine on 4.2 without
IPV6 enabled.  Or has that always been a requirement and I just got lucky
somehow.  I'm looking through the docs now.

Regardless, thank you very much for the help Flo!

Jay

On Tue, Dec 13, 2016 at 10:20 AM, Florence Blanc-Renaud 
wrote:

> On 12/13/2016 04:41 PM, jay wrote:
>
>> Maybe this will help more, I noticed this error in the Apache logs
>>
>> [Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO:
>> [jsonserver_kerb] ad...@ipa.us-WEST-2.COMPUTE.INTERNAL:
>> cert_show/1(u'1', version=u'2.213'): CertificateOperationError
>> [Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316]
>> (111)Connection refused: AH00957: AJP: attempt to connect to
>> 127.0.0.1:8009  (localhost) failed
>> [Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
>> ap_proxy_connect_backend disabling worker for (localhost) for 60s
>> [Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client
>> 172.31.0.254:39646 ] AH00896: failed to make
>> connection to backend: localhost
>> [Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
>> ra.get_certificate(): Unable to communicate with CMS (503)
>>
>>
>> So whatever is running on port 8009 isn't responding or setup properly.
>>
>> Jay
>>
>> On Tue, Dec 13, 2016 at 8:46 AM, jay > > wrote:
>>
>> Thank you for the response Flo.  So I do see Apache running and
>> listening on port 443.  However, running that command I get a 503
>>
>> *   Trying 172.31.0.254...
>> * Connected to ip-172-31-0-254.us-west-2.compute.internal
>> (172.31.0.254) port 443 (#0)
>> * Initializing NSS with certpath: sql:/etc/httpd/alias
>> *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>>   CApath: none
>> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
>> * Server certificate:
>> *   subject:
>> CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-
>> 2.COMPUTE.INTERNAL
>> *   start date: Dec 13 14:33:16 2016 GMT
>> *   expire date: Dec 14 14:33:16 2018 GMT
>> *   common name: ip-172-31-0-254.us-west-2.compute.internal
>> *   issuer: CN=Certificate
>> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
>> > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
>> > User-Agent: curl/7.29.0
>> > Host: ip-172-31-0-254.us-west-2.compute.internal
>> > Accept: */*
>> >
>> * NSS: using client certificate: ipaCert
>> *   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
>> *   start date: Dec 13 14:32:28 2016 GMT
>> *   expire date: Dec 03 14:32:28 2018 GMT
>> *   common name: IPA RA
>> *   issuer: CN=Certificate
>> Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
>> < HTTP/1.1 503 Service Unavailable
>> < Date: Tue, 13 Dec 2016 14:44:00 GMT
>> < Server: Apache
>> < Content-Length: 299
>> < Connection: close
>> < Content-Type: text/html; charset=iso-8859-1
>>
>> [root@ip-172-31-0-254 ~]# cat out.html
>> 
>> 
>> 503 Service Unavailable
>> 
>> Service Unavailable
>> The server is temporarily unable to service your
>> request due to maintenance downtime or capacity
>> problems. Please try again later.
>> 
>> [root@ip-172-31-0-254 ~]#
>>
>>
>> What would cause the service to be unavailable?  Maybe the installer
>> changed and I need to provide another option now that I didn't have
>> to before the version upgrade?
>>
>> Hi Jay,
>
> I am not completely familiar with Tomcat, but I understand so far that the
> httpd server is configured to redirect requests on displayBySerial to
> Tomcat with this setting in the file /etc/httpd/conf.d/ipa-pki-proxy.conf:
>
>  agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/
> eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector">
> NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
> NSSVerifyClient require
> ProxyPassMatch ajp://localhost:8009
> ProxyPassReverse ajp://localhost:8009
> 
>
> And this port must be configured in /etc/pki/pki-tomcat/server.xml:
>  protocol="AJP/1.3"
> redirectPort="8443"
> address="::1" />
>
> In my setup I also have /etc/hosts defining localhost:
> 127.0.0.1   localhost localhost.localdomain localhost4
> localhost4.localdomain4
> ::1 localhost localhost.localdomain localhost6
> localhost6.localdomain6
>
>
> Can you check that you also have those settings? If yes, then I assume
> that Tomcat is not able to create the AJP connector on port 8009.
> When PKI is started, you should find a trace of the connector
> initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log:
>

Re: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[Florence Blanc-Renaud]

On 12/13/2016 04:41 PM, jay wrote:

Maybe this will help more, I noticed this error in the Apache logs

[Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO:
[jsonserver_kerb] ad...@ipa.us-WEST-2.COMPUTE.INTERNAL:
cert_show/1(u'1', version=u'2.213'): CertificateOperationError
[Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316]
(111)Connection refused: AH00957: AJP: attempt to connect to
127.0.0.1:8009  (localhost) failed
[Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client
172.31.0.254:39646 ] AH00896: failed to make
connection to backend: localhost
[Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
ra.get_certificate(): Unable to communicate with CMS (503)


So whatever is running on port 8009 isn't responding or setup properly.

Jay

On Tue, Dec 13, 2016 at 8:46 AM, jay mailto:titleistf...@gmail.com>> wrote:

Thank you for the response Flo.  So I do see Apache running and
listening on port 443.  However, running that command I get a 503

*   Trying 172.31.0.254...
* Connected to ip-172-31-0-254.us-west-2.compute.internal
(172.31.0.254) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/httpd/alias
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject:

CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:33:16 2016 GMT
*   expire date: Dec 14 14:33:16 2018 GMT
*   common name: ip-172-31-0-254.us-west-2.compute.internal
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ip-172-31-0-254.us-west-2.compute.internal
> Accept: */*
>
* NSS: using client certificate: ipaCert
*   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:32:28 2016 GMT
*   expire date: Dec 03 14:32:28 2018 GMT
*   common name: IPA RA
*   issuer: CN=Certificate
Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
< HTTP/1.1 503 Service Unavailable
< Date: Tue, 13 Dec 2016 14:44:00 GMT
< Server: Apache
< Content-Length: 299
< Connection: close
< Content-Type: text/html; charset=iso-8859-1

[root@ip-172-31-0-254 ~]# cat out.html


503 Service Unavailable

Service Unavailable
The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.

[root@ip-172-31-0-254 ~]#


What would cause the service to be unavailable?  Maybe the installer
changed and I need to provide another option now that I didn't have
to before the version upgrade?


Hi Jay,

I am not completely familiar with Tomcat, but I understand so far that 
the httpd server is configured to redirect requests on displayBySerial 
to Tomcat with this setting in the file 
/etc/httpd/conf.d/ipa-pki-proxy.conf:


"^/ca/agent/ca/displayBySerial|^/ca/agent/ca/doRevoke|^/ca/agent/ca/doUnrevoke|^/ca/agent/ca/updateDomainXML|^/ca/eeca/ca/profileSubmitSSLClient|^/kra/agent/kra/connector">

NSSOptions +StdEnvVars +ExportCertData +StrictRequire +OptRenegotiate
NSSVerifyClient require
ProxyPassMatch ajp://localhost:8009
ProxyPassReverse ajp://localhost:8009


And this port must be configured in /etc/pki/pki-tomcat/server.xml:


In my setup I also have /etc/hosts defining localhost:
127.0.0.1   localhost localhost.localdomain localhost4 
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 
localhost6.localdomain6



Can you check that you also have those settings? If yes, then I assume 
that Tomcat is not able to create the AJP connector on port 8009.
When PKI is started, you should find a trace of the connector 
initialization in /var/log/pki/pki-tomcat/catalina.$DATE.log:


12-Dec-2016 13:54:17.579 INFO [main] 
org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler 
["ajp-nio-0:0:0:0:0:0:0:1-8009"]
12-Dec-2016 13:54:25.076 INFO [main] 
org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler 
["ajp-nio-0:0:0:0:0:0:0:1-8009"]
12-Dec-2016 13:56:33.683 INFO [ajp-nio-0:0:0:0:0:0:0:1-8009-exec-1] 
org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.processApplication 
RESTEASY002225: Deploying javax.ws.rs.core.Application: class 
org.dogtagpki.server.ca.rest.CAApplication


Next steps to debug would be to increase Tomcat logs.
Flo.



Thanks,
Jay

On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud
mailto:f...@redhat.com>> wrote:

On 12/12/2016 10:32 PM, jay wrote:

Hel

Re: [Freeipa-users] DNS search timeouts and incomplete results

[Martin Basti]

Tomas already replied to you, copying here as archives are currently 
offline to prevent spam


"""

Hi,

you seem to be hitting the size limit on LDAP side. To verify, check

ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit


If you really need to increase this size limit, you will have to modify 
the nsslapd-sizelimit in cn=config.


"""

Martin


On 13.12.2016 17:06, Mike Driscoll wrote:

Any thoughts about this sizelimit bug?

Mike




On Nov 28, 2016, at 14:44, Mike Driscoll  wrote:

I'm running:
# rpm -qa | grep ipa-server
ipa-server-4.4.0-12.0.1.el7.x86_64
ipa-server-dns-4.4.0-12.0.1.el7.noarch
ipa-server-common-4.4.0-12.0.1.el7.noarch

Searching DNS for all hostnames containing "qa" times out in the GUI.  Setting 
aside the option to change server defaults, this cli command isn't giving me the content 
I need:

# ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
ipa: WARNING: Search result has been truncated: Configured size limit exceeded

It seems like the sizelimit parameter greater than two thousand is being 
ignored:

# ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
...
---
Number of entries returned 1900
---

# ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
...
---
Number of entries returned 2000
---

Any suggestions?

Mike




--
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] DNS search timeouts and incomplete results

[Mike Driscoll]

Any thoughts about this sizelimit bug?

Mike



> On Nov 28, 2016, at 14:44, Mike Driscoll  wrote:
> 
> I'm running:
> # rpm -qa | grep ipa-server
> ipa-server-4.4.0-12.0.1.el7.x86_64
> ipa-server-dns-4.4.0-12.0.1.el7.noarch
> ipa-server-common-4.4.0-12.0.1.el7.noarch
> 
> Searching DNS for all hostnames containing "qa" times out in the GUI.  
> Setting aside the option to change server defaults, this cli command isn't 
> giving me the content I need:
> 
> # ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
> ipa: WARNING: Search result has been truncated: Configured size limit exceeded
> 
> It seems like the sizelimit parameter greater than two thousand is being 
> ignored:
> 
> # ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
> ...
> ---
> Number of entries returned 1900
> ---
> 
> # ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
> ...
> ---
> Number of entries returned 2000
> ---
> 
> Any suggestions?
> 
> Mike


-- 
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] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[jay]

Maybe this will help more, I noticed this error in the Apache logs

[Tue Dec 13 09:33:37.774921 2016] [:error] [pid 2309] ipa: INFO:
[jsonserver_kerb] ad...@ipa.us-WEST-2.COMPUTE.INTERNAL: cert_show/1(u'1',
version=u'2.213'): CertificateOperationError
[Tue Dec 13 09:35:29.141847 2016] [proxy:error] [pid 2316] (111)Connection
refused: AH00957: AJP: attempt to connect to 127.0.0.1:8009 (localhost)
failed
[Tue Dec 13 09:35:29.141881 2016] [proxy:error] [pid 2316] AH00959:
ap_proxy_connect_backend disabling worker for (localhost) for 60s
[Tue Dec 13 09:35:29.141900 2016] [proxy_ajp:error] [pid 2316] [client
172.31.0.254:39646] AH00896: failed to make connection to backend: localhost
[Tue Dec 13 09:35:29.142412 2016] [:error] [pid 2310] ipa: ERROR:
ra.get_certificate(): Unable to communicate with CMS (503)


So whatever is running on port 8009 isn't responding or setup properly.

Jay

On Tue, Dec 13, 2016 at 8:46 AM, jay  wrote:

> Thank you for the response Flo.  So I do see Apache running and listening
> on port 443.  However, running that command I get a 503
>
> *   Trying 172.31.0.254...
> * Connected to ip-172-31-0-254.us-west-2.compute.internal (172.31.0.254)
> port 443 (#0)
> * Initializing NSS with certpath: sql:/etc/httpd/alias
> *   CAfile: /etc/pki/tls/certs/ca-bundle.crt
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> *   subject: CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-
> WEST-2.COMPUTE.INTERNAL
> *   start date: Dec 13 14:33:16 2016 GMT
> *   expire date: Dec 14 14:33:16 2018 GMT
> *   common name: ip-172-31-0-254.us-west-2.compute.internal
> *   issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> > GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> > User-Agent: curl/7.29.0
> > Host: ip-172-31-0-254.us-west-2.compute.internal
> > Accept: */*
> >
> * NSS: using client certificate: ipaCert
> *   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> *   start date: Dec 13 14:32:28 2016 GMT
> *   expire date: Dec 03 14:32:28 2018 GMT
> *   common name: IPA RA
> *   issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> < HTTP/1.1 503 Service Unavailable
> < Date: Tue, 13 Dec 2016 14:44:00 GMT
> < Server: Apache
> < Content-Length: 299
> < Connection: close
> < Content-Type: text/html; charset=iso-8859-1
>
> [root@ip-172-31-0-254 ~]# cat out.html
> 
> 
> 503 Service Unavailable
> 
> Service Unavailable
> The server is temporarily unable to service your
> request due to maintenance downtime or capacity
> problems. Please try again later.
> 
> [root@ip-172-31-0-254 ~]#
>
>
> What would cause the service to be unavailable?  Maybe the installer
> changed and I need to provide another option now that I didn't have to
> before the version upgrade?
>
> Thanks,
> Jay
>
> On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud 
> wrote:
>
>> On 12/12/2016 10:32 PM, jay wrote:
>>
>>> Hello,
>>>
>>> I have been testing freeipa on CentOS 7 for a while now with a
>>> relatively simple setup, just a single server and 12 or so Linux clients
>>> in AWS.  I went to rebuild the environment today and part of my Ansible
>>> playbook failed with this error
>>>
>>> ipa: ERROR: Certificate operation cannot be completed: Unable to
>>> communicate with CMS (503)
>>>
>>> This is the command that failed
>>>
>>> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt
>>>
>>> I noticed the version I was using on Friday was
>>> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64.  But now I'm getting
>>> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated
>>> over the weekend.
>>>
>>> Is there a known issue running cert-show with this version?  I can't
>>> find anything in the debug logs that point to something wrong.  Running
>>> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work
>>> just fine.
>>>
>>> Can someone offer some advice or pointer to what might be going on?  I'm
>>> invoking the install with these options and it has worked flawlessly
>>> before this new version
>>>
>>> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments
>>> [] and options: {'no_dns_
>>> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False,
>>> 'ip_addresses': [CheckedIPAddr
>>> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None,
>>> 'http_cert_files': None, 'no_ntp': N
>>> one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type':
>>> None, 'ssh_trust_dns': True
>>> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None,
>>> 'http_cert_name': None, 'dirsrv_
>>> cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm':
>>> None, 'no_reverse': None,
>>>  'subject': None, 'unattended': True, 'auto_reverse': None,
>>> 'auto_forwarders': None, 'no_host_dns'
>>> : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role':
>>> None, 'realm_name': 'IPA.U
>>> S-WEST-2.COMPUTE.INTERNAL', 'forwarder

Re: [Freeipa-users] With freeipa 4.4.0-14 on CentOS 7 cert-show fails

[jay]

Thank you for the response Flo.  So I do see Apache running and listening
on port 443.  However, running that command I get a 503

*   Trying 172.31.0.254...
* Connected to ip-172-31-0-254.us-west-2.compute.internal (172.31.0.254)
port 443 (#0)
* Initializing NSS with certpath: sql:/etc/httpd/alias
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
*   subject:
CN=ip-172-31-0-254.us-west-2.compute.internal,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:33:16 2016 GMT
*   expire date: Dec 14 14:33:16 2018 GMT
*   common name: ip-172-31-0-254.us-west-2.compute.internal
*   issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
> GET /ca/agent/ca/displayBySerial?serialNumber=1 HTTP/1.1
> User-Agent: curl/7.29.0
> Host: ip-172-31-0-254.us-west-2.compute.internal
> Accept: */*
>
* NSS: using client certificate: ipaCert
*   subject: CN=IPA RA,O=IPA.US-WEST-2.COMPUTE.INTERNAL
*   start date: Dec 13 14:32:28 2016 GMT
*   expire date: Dec 03 14:32:28 2018 GMT
*   common name: IPA RA
*   issuer: CN=Certificate Authority,O=IPA.US-WEST-2.COMPUTE.INTERNAL
< HTTP/1.1 503 Service Unavailable
< Date: Tue, 13 Dec 2016 14:44:00 GMT
< Server: Apache
< Content-Length: 299
< Connection: close
< Content-Type: text/html; charset=iso-8859-1

[root@ip-172-31-0-254 ~]# cat out.html


503 Service Unavailable

Service Unavailable
The server is temporarily unable to service your
request due to maintenance downtime or capacity
problems. Please try again later.

[root@ip-172-31-0-254 ~]#


What would cause the service to be unavailable?  Maybe the installer
changed and I need to provide another option now that I didn't have to
before the version upgrade?

Thanks,
Jay

On Tue, Dec 13, 2016 at 1:56 AM, Florence Blanc-Renaud 
wrote:

> On 12/12/2016 10:32 PM, jay wrote:
>
>> Hello,
>>
>> I have been testing freeipa on CentOS 7 for a while now with a
>> relatively simple setup, just a single server and 12 or so Linux clients
>> in AWS.  I went to rebuild the environment today and part of my Ansible
>> playbook failed with this error
>>
>> ipa: ERROR: Certificate operation cannot be completed: Unable to
>> communicate with CMS (503)
>>
>> This is the command that failed
>>
>> /usr/bin/ipa cert-show 1 --out=/root/cacert.crt
>>
>> I noticed the version I was using on Friday was
>> ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64.  But now I'm getting
>> ipa-server-4.4.0-14.el7.centos.x86_64 installed, so the repo was updated
>> over the weekend.
>>
>> Is there a known issue running cert-show with this version?  I can't
>> find anything in the debug logs that point to something wrong.  Running
>> 'ipa cert-find' and 'getcert list -d /etc/httpd/alias -n ipaCert' work
>> just fine.
>>
>> Can someone offer some advice or pointer to what might be going on?  I'm
>> invoking the install with these options and it has worked flawlessly
>> before this new version
>>
>> 2016-12-12T21:05:21Z DEBUG ipa-server-install was invoked with arguments
>> [] and options: {'no_dns_
>> sshfp': None, 'ignore_topology_disconnect': None, 'verbose': False,
>> 'ip_addresses': [CheckedIPAddr
>> ess('172.31.0.235')], 'domainlevel': None, 'mkhomedir': None,
>> 'http_cert_files': None, 'no_ntp': N
>> one, 'reverse_zones': None, 'no_forwarders': None, 'external_ca_type':
>> None, 'ssh_trust_dns': True
>> , 'domain_name': 'ipa.us-west-2.compute.internal', 'idmax': None,
>> 'http_cert_name': None, 'dirsrv_
>> cert_files': None, 'no_dnssec_validation': None, 'ca_signing_algorithm':
>> None, 'no_reverse': None,
>>  'subject': None, 'unattended': True, 'auto_reverse': None,
>> 'auto_forwarders': None, 'no_host_dns'
>> : None, 'no_sshd': None, 'no_ui_redirect': None, 'ignore_last_of_role':
>> None, 'realm_name': 'IPA.U
>> S-WEST-2.COMPUTE.INTERNAL', 'forwarders':
>> [CheckedIPAddress('172.31.0.2')], 'idstart': 5000, 'exte
>> rnal_ca': None, 'no_ssh': None, 'external_cert_files': None,
>> 'no_hbac_allow': None, 'forward_polic
>> y': None, 'dirsrv_cert_name': None, 'ca_cert_files': None, 'zonemgr':
>> None, 'quiet': False, 'setup
>> _dns': True, 'host_name': 'ip-172-31-0-235.us-west-2.compute.internal',
>> 'dirsrv_config_file': None
>> , 'log_file': None, 'allow_zone_overlap': None, 'uninstall': False}
>> 2016-12-12T21:05:21Z DEBUG IPA version 4.4.0-14.el7.centos
>>
>> Thank you
>> Jay
>>
>>
>>
> Hi,
>
> the ipa cert-show command is communicating with Dogtag, using port 443.
> Can you check if Dogtag is properly responding on this port?
>
> $ SSL_DIR=/etc/httpd/alias/ curl -v -E ipaCert:`cat
> /etc/httpd/alias/pwdfile.txt` https://hostname.domainname:44
> 3/ca/agent/ca/displayBySerial?serialNumber=1 -o out.html
>
> The issue can be that Dogtag is down, or a SSL issue (the certificate
> ipaCert in /etc/httpd/alias is used to authenticate the client to Dogtag).
>
> HTH,
> Flo.
>
-- 
Manage your subscription for the Freeipa-users mailing l

Re: [Freeipa-users] Failed ipa-client-install with IPA Replica

[David Kupka]

On 13/12/16 05:44, beeth beeth wrote:

I have two IPA servers ipaprd1.example.com and ipaprd2.example.com, running
ipa 4.4 on RHEL7. When I tried to install/configure the client on a RHEL6
system(called ipadev6), I had issue when I tried to enroll it with the
replica(ipaprd2), while no issue with the primary(ipaprd1):

# ipa-client-install --domain=ipa.example.com --server=ipaprd1.example.com
--server=ipaprd2.example.com --hostname=ipadev6.example.com
LDAP Error: Protocol error: unsupported extended operation
Autodiscovery of servers for failover cannot work with this configuration.
If you proceed with the installation, services will be configured to always
access the discovered server for all operations and will not fail over to
other servers in case of failure.
Proceed with fixed values and no DNS discovery? [no]

Then I tried to run ipa-client-install to enroll with the replica(ipaprd2),
with debug mode, I got this:

# ipa-client-install --domain=ipa.example.com --server=ipaprd2.example.com
 --hostname=ipadev6.example.com -d
/usr/sbin/ipa-client-install was invoked with options: {'domain': '
ipa.example.com', 'force': False, 'realm_name': None,
'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False,
'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master':
False, 'ntp_server': None, 'nisdomain': None, 'no_nisdomain': False,
'principal': None, 'hostname': 'ipadev6.example.com', 'no_ac': False,
'unattended': None, 'sssd': True, 'trust_sshfp': False, 'kinit_attempts':
5, 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join':
False, 'ca_cert_file': None, 'server': ['ipaprd2.example.com'],
'prompt_password': False, 'permit': False, 'debug': True, 'preserve_sssd':
False, 'uninstall': False}
missing options might be asked for interactively later
Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index'
Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state'
[IPA Discovery]
Starting IPA discovery with domain=ipa.example.com, servers=['
ipaprd2.example.com'], hostname=ipadev6.example.com
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of _kerberos.ipa.example.com.
No DNS record found
Search DNS for SRV record of _kerberos._udp.ipa.example.com.
No DNS record found
SRV record for KDC not found! Domain: ipa.example.com
[LDAP server check]
Verifying that ipaprd2.example.com (realm None) is an IPA server
Init LDAP connection with: ldap://ipaprd2.example.com:389
LDAP Error: Protocol error: unsupported extended operation
Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com,
kdc=None, basedn=None
Validated servers:
will use discovered domain: ipa.example.com
IPA Server not found
[IPA Discovery]
Starting IPA discovery with domain=ipa.example.com, servers=['
ipaprd2.example.com'], hostname=ipadev6.example.com
Server and domain forced
[Kerberos realm search]
Search DNS for TXT record of _kerberos.ipa.example.com.
No DNS record found
Search DNS for SRV record of _kerberos._udp.ipa.example.com.
No DNS record found
SRV record for KDC not found! Domain: ipa.example.com
[LDAP server check]
Verifying that ipaprd2.example.com (realm None) is an IPA server
Init LDAP connection with: ldap://ipaprd2.example.com:389
LDAP Error: Protocol error: unsupported extended operation
Discovery result: UNKNOWN_ERROR; server=None, domain=ipa.example.com,
kdc=None, basedn=None
Validated servers:
Failed to verify that ipaprd2.example.com is an IPA Server.
This may mean that the remote server is not up or is not reachable due to
network or firewall settings.
Please make sure the following ports are opened in the firewall settings:
 TCP: 80, 88, 389
 UDP: 88 (at least one of TCP/UDP ports 88 has to be open)
Also note that following ports are necessary for ipa-client working
properly after enrollment:
 TCP: 464
 UDP: 464, 123 (if NTP enabled)
(ipaprd2.example.com: Provided as option)
Installation failed. Rolling back changes.
IPA client is not configured on this system.


I double checked the services running on the replica, all looked well:
ports are listening, and I could telnet the ports from the client(ipadev6).
I could run "ldapserach" command to talk to the replica(ipaprd2) from this
client(ipadev6), with pulling out all the LDAP records.

Also, I have another test box running RHEL7, and no issue at all to run the
exact same ipa-client-install command on that RHEL7 box. So could there be
a bug on the ipa-client software on RHEL6, to talk to IPA sever running on
RHEL7? Please advise. Thank you!

Best regards,
Beeth




Hello Beeth,
I've tried to reproduce the problem you described with 7.3 (ipa-server 
4.4.0-12) on master and replica and 6.9 (ipa-client 3.0.0-51) on client 
and it worked for me as expected.

I've done these steps:
[master] # ipa-server-install -a Secret123 -p Secret123 --domain 
example.test --realm EXAMPLE.TEST --setup-dns --auto-forwarders -U
[replica] # ipa-client-install -p admin -w Secre

[Freeipa-users] How to disable First time password change on IPA user

[Ben .T.George]

HI

How to disable first time password change on newly created user from web UI

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

[Freeipa-users] ipa.p11-kit: Permission denied

[lejeczek]

hi all

I see this when I restart httpd:

[Tue Dec 13 10:26:06.945668 2016] [core:notice] [pid 47548] 
AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
p11-kit: couldn't open and map file: 
/etc/pki/ca-trust/source/ipa.p11-kit: Permission denied
p11-kit: couldn't open and map file: 
/etc/pki/ca-trust/source/ipa.p11-kit: Permission denied

...

and I wonder if it has something to do with IPA? And if yes 
then is it critical? IPA seems to work normal.


many thanks,
L.

--
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 realm for different domain

[David Kupka]

On 13/12/16 07:52, Stephen Ingram wrote:

On Sun, Dec 11, 2016 at 11:31 PM, David Kupka  wrote:



yes you can do it. DNS domain and Kerberos realm are two different things.
It's common and AFAIK recommended to capitalize DNS domain to get the realm
but it's not required.
If you really want to have them different make sure:
a) anotherdomain.com is under your control,
b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS
AD, ...) with ANOTHERDOMAIN.COM  realm
deployed.

With FreeIPA you can run
# ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM


But before you do, why do you want to have the realm different from the
domain?



David-

We have multiple domains that we want to manage under one Kerberos realm. I
see that's it's possible for FreeIPA to manage multiple realms, but, for
simplicity, I'd rather use just one and have all domains underneath:

REALM.COM
controls example1.com, example2.com, example3.com, etc.

Since we control all domain's DNS, we would create text records for each of
the example{x}.com domains pointing to REALM.COM Kerberos realm. We would
also create SRV records for each of the example{x}.com domains directing
Kerberos lookups to REALM.COM. I know it's a little unorthodox, but I'd
like to do it so we can keep everything in one easily managed lot.

Steve

P.S. I got several pornny spammy replies to this message. Is someone
sneaking into this list somehow?




Hello Steve,
in fact it's not possible to manage multiple Kerberos realms in one 
FreeIPA deployment. And judging from your description it also isn't what 
you want.
On the other hand, having one realm and multiple DNS domains is standard 
situation and usually the name of the realm is derived from the primary 
domain (e.g. the one that matches organization name). If all your 
domains are equal just pick the one that you're most sure you'll keep 
under your control.


Regarding the spamming problem, we're all receiving it and the main 
problem is that the spam is not targeting freeipa-users@ list but the 
individual addresses in conversations. There's not much we can do but 
Simo is trying to find a solution.

--
David Kupka

--
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