Re: [Freeipa-users] ipa-server-install fails at DogTag restart

[Fraser Tweedale]

On Wed, Dec 14, 2016 at 05:35:35PM +, Tommy Nikjoo wrote:
> Hi,
> 
> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
> keep getting an error when it tries to restart DogTag
> 
>   [26/31]: restarting certificate server
> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
> the Dogtag instance.See the installation log for details.
>   [27/31]: migrating certificate profiles to LDAP
>   [error] NetworkError: cannot connect to
> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
> ipa-server-install command failed. See /var/log/ipaserver-install.log
> for more information
> 
> 
> The log shows the following error
> 
> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
> SSL Server
> 2016-12-14T16:53:05Z DEBUG cert valid True for
> "CN=ldap.example.com,O=EXAMPLE.COM"
> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
> 2016-12-14T16:53:05Z DEBUG response status 200
> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
> 2016 16:53:05 GMT', 'content-type': 'application/xml'}
> 2016-12-14T16:53:05Z DEBUG response body ' encoding="UTF-8" standalone="yes"?> id="ipara">iparaCertificate Manager
> AgentsRegistration Manager Agents'
> 2016-12-14T16:53:05Z DEBUG request POST
> https://ldap.example.com:8443/ca/rest/profiles/raw
> 2016-12-14T16:53:05Z DEBUG request body
> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
> certificates with IECUserRoles extension via IPA-RA agent
> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
> Agent-Authenticated Server Certificate
> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
> Name
> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
> Name
> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
> Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity
> Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key
> Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key
> Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No
> Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority
> Key Identifier
> Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No
> Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA
> Extension
> 

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

[beeth beeth]

Hi Flo,

Thanks for the great hint! I reran the ipa-client-install on the rhel6
box(ipadev6), and monitored the access log file you mentioned on the
replica:

# ipa-client-install --domain=ipa.example.com --server=ipaprd2.example.com
 --hostname=ipadev6.example.com -d

( ipaprd2 = primary IPA server on RHEL7; ipadev6 = replica on RHEL6 )

AFTER about 3 seconds, I saw these on the replica ipaprd2:
[14/Dec/2016:13:11:41.071421132 -0500] conn=1040 fd=73 slot=73 connection
from  to 
[14/Dec/2016:13:11:41.071880026 -0500] conn=1040 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.071964217 -0500] conn=1040 op=0 RESULT err=2 tag=120
nentries=0 etime=0
[14/Dec/2016:13:11:41.073275674 -0500] conn=1040 op=1 UNBIND
[14/Dec/2016:13:11:41.073307101 -0500] conn=1040 op=1 fd=73 closed - U1
[14/Dec/2016:13:11:41.074782496 -0500] conn=1041 fd=73 slot=73 connection
from  to 
[14/Dec/2016:13:11:41.074985233 -0500] conn=1041 op=0 EXT
oid="1.3.6.1.4.1.1466.20037"
[14/Dec/2016:13:11:41.075022849 -0500] conn=1041 op=0 RESULT err=2 tag=120
nentries=0 etime=0
[14/Dec/2016:13:11:41.075448887 -0500] conn=1041 op=1 UNBIND
[14/Dec/2016:13:11:41.075460964 -0500] conn=1041 op=1 fd=73 closed - U1
[14/Dec/2016:13:11:49.006146850 -0500] conn=1029 op=8 UNBIND
[14/Dec/2016:13:11:49.006181982 -0500] conn=1029 op=8 fd=66 closed - U1

So I did see the err=2, and oid="1.3.6.1.4.1.1466.20037", I checked the oid
and got:

1.3.6.1.4.1.1466.20037: StartTLS Request (RFC 4511)

It looked to be related with TLS... pease advise. Thanks!




On Wed, Dec 14, 2016 at 7:57 AM, Florence Blanc-Renaud 
wrote:

> On 12/14/2016 01:08 PM, beeth beeth wrote:
>
>> Thanks David. I installed both the master and replica IPA servers with
>> third-party certificates(Verisign), but I doubt that could be the issue,
>> because I had no problem to run the same ipa-client-install command on a
>> RHEL7 machine(of course, the --hostname used a different hostname of the
>> server). And I had no problem to run the ipa-client-install command with
>> --server= on such RHEL6 machine. So what could cause the LDAP
>> communication failed during the client enrollment with the replica? Is
>> there a way I can troubleshoot this by running some commands? So far I
>> did telnet to check the open ports, as well as run the ldapsearch
>> towards the replica. Thanks again!
>>
>>
>> On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > > wrote:
>>
>> 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
>> '],
>> 

Re: [Freeipa-users] FreeIPA and vSphere

[Simo Sorce]

On Wed, 2016-12-14 at 19:29 +0200, Alexander Bokovoy wrote:
> On ke, 14 joulu 2016, Serhii Honchar wrote:
> >Alexander,
> >as per RFC2696 in such case:
> >---
> >
> >If the server does not support this control, the server
> >   MUST return an error of unsupportedCriticalExtension if the client
> >   requested it as critical,
> >
> >---
> >So  in case slapi-nis plugin doesn't support "paged results control", it is
> >quite incorrect to absolutely ignore control regardless of their
> >"criticality". To comply with RFC2696 slapi-nis plugin shall reply
> >with "unsupportedCriticalExtension"
> >error in such cases. Am i right?
> That's right, but slapi-nis never supported paged search results before
> and I'm not sure we want it to do that with the current code as it is
> not trivial at all.
> 
> You may file a bug about paged results but I suspect it will start
> working with the refactoring of slapi-nis we plan for global catalog
> support in FreeIPA 4.5/4.6 where we'll move content of the slapi-nis
> virtual memory cache to a proper database backend in a separate 389-ds
> instance.

Yes it is definitely a bug, but not an easy fix, please do file a bug,
however it will take some time before we can fix it.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA and vSphere

[Alexander Bokovoy]

On ke, 14 joulu 2016, Serhii Honchar wrote:

Alexander,
as per RFC2696 in such case:
---

If the server does not support this control, the server
  MUST return an error of unsupportedCriticalExtension if the client
  requested it as critical,

---
So  in case slapi-nis plugin doesn't support "paged results control", it is
quite incorrect to absolutely ignore control regardless of their
"criticality". To comply with RFC2696 slapi-nis plugin shall reply
with "unsupportedCriticalExtension"
error in such cases. Am i right?

That's right, but slapi-nis never supported paged search results before
and I'm not sure we want it to do that with the current code as it is
not trivial at all.

You may file a bug about paged results but I suspect it will start
working with the refactoring of slapi-nis we plan for global catalog
support in FreeIPA 4.5/4.6 where we'll move content of the slapi-nis
virtual memory cache to a proper database backend in a separate 389-ds
instance.

--
/ Alexander Bokovoy

--
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-server-install fails at DogTag restart

[Tommy Nikjoo]

Hi,

I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
keep getting an error when it tries to restart DogTag

  [26/31]: restarting certificate server
ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
the Dogtag instance.See the installation log for details.
  [27/31]: migrating certificate profiles to LDAP
  [error] NetworkError: cannot connect to
'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
ipa.ipapython.install.cli.install_tool(Server): ERRORThe
ipa-server-install command failed. See /var/log/ipaserver-install.log
for more information


The log shows the following error

2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
SSL Server
2016-12-14T16:53:05Z DEBUG cert valid True for
"CN=ldap.example.com,O=EXAMPLE.COM"
2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
2016-12-14T16:53:05Z DEBUG response status 200
2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
2016 16:53:05 GMT', 'content-type': 'application/xml'}
2016-12-14T16:53:05Z DEBUG response body 'iparaCertificate Manager
AgentsRegistration Manager Agents'
2016-12-14T16:53:05Z DEBUG request POST
https://ldap.example.com:8443/ca/rest/profiles/raw
2016-12-14T16:53:05Z DEBUG request body
'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
certificates with IECUserRoles extension via IPA-RA agent
authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
Agent-Authenticated Server Certificate
Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
Name
Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
Name
Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
Constraint\npolicyset.serverCertSet.2.constraint.params.range=740\npolicyset.serverCertSet.2.constraint.params.notBeforeCheck=false\npolicyset.serverCertSet.2.constraint.params.notAfterCheck=false\npolicyset.serverCertSet.2.default.class_id=validityDefaultImpl\npolicyset.serverCertSet.2.default.name=Validity
Default\npolicyset.serverCertSet.2.default.params.range=731\npolicyset.serverCertSet.2.default.params.startTime=0\npolicyset.serverCertSet.3.constraint.class_id=keyConstraintImpl\npolicyset.serverCertSet.3.constraint.name=Key
Constraint\npolicyset.serverCertSet.3.constraint.params.keyType=RSA\npolicyset.serverCertSet.3.constraint.params.keyParameters=1024,2048,3072,4096\npolicyset.serverCertSet.3.default.class_id=userKeyDefaultImpl\npolicyset.serverCertSet.3.default.name=Key
Default\npolicyset.serverCertSet.4.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.4.constraint.name=No
Constraint\npolicyset.serverCertSet.4.default.class_id=authorityKeyIdentifierExtDefaultImpl\npolicyset.serverCertSet.4.default.name=Authority
Key Identifier
Default\npolicyset.serverCertSet.5.constraint.class_id=noConstraintImpl\npolicyset.serverCertSet.5.constraint.name=No
Constraint\npolicyset.serverCertSet.5.default.class_id=authInfoAccessExtDefaultImpl\npolicyset.serverCertSet.5.default.name=AIA
Extension
Default\npolicyset.serverCertSet.5.default.params.authInfoAccessADEnable_0=true\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocationType_0=URIName\npolicyset.serverCertSet.5.default.params.authInfoAccessADLocation_0=http://ipa-ca.example.com/ca/ocsp\npolicyset.serverCertSet.5.default.params.authInfoAccessADMethod_0=1.3.6.1.5.5.7.48.1\npolicyset.serverCertSet.5.default.params.authInfoAccessCritical=false\npolicyset.serverCertSet.5.default.params.authInfoAccessNumADs=1\npolicyset.serverCertSet.6.constraint.class_id=keyUsageExtConstraintImpl\npolicyset.serverCertSet.6.constraint.name=Key
Usage Extension

Re: [Freeipa-users] Confirming no extra/special ports need to be opened for replication traffic?

[Chris Dagdigian]

Much appreciated, thank you!

Martin Babinsky wrote:
IIRC in IPA v3.0 there was 7389 port used for CA replication, but in 
more recent versions this is not required anymore.


--
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] Confirming no extra/special ports need to be opened for replication traffic?

[Martin Babinsky]

On 12/14/2016 05:50 PM, Chris Dagdigian wrote:


Been reading various generations of documentation to find out if I need
additional TCP or UDP ports opened for IPA replication between
VPN-connected dataceners.

I think the modern answer is no? We just need the standard IPA ports
open between all of the IPA master/replicas that chat to each other?

TCP Ports:
  * 80, 443: HTTP/HTTPS
  * 389, 636: LDAP/LDAPS
  * 88, 464: kerberos
  * 53: bind
UDP Ports:
  * 88, 464: kerberos
  * 53: bind
  * 123: ntp


-Chris



Hi Chris,

IIRC in IPA v3.0 there was 7389 port used for CA replication, but in 
more recent versions this is not required anymore.


--
Martin^3 Babinsky

--
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] Confirming no extra/special ports need to be opened for replication traffic?

[Chris Dagdigian]

Been reading various generations of documentation to find out if I need 
additional TCP or UDP ports opened for IPA replication between 
VPN-connected dataceners.


I think the modern answer is no? We just need the standard IPA ports 
open between all of the IPA master/replicas that chat to each other?


TCP Ports:
  * 80, 443: HTTP/HTTPS
  * 389, 636: LDAP/LDAPS
  * 88, 464: kerberos
  * 53: bind
UDP Ports:
  * 88, 464: kerberos
  * 53: bind
  * 123: ntp


-Chris


--
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] FreeIPA and vSphere

[Serhii Honchar]

Alexander,
as per RFC2696 in such case:
---

If the server does not support this control, the server
   MUST return an error of unsupportedCriticalExtension if the client
   requested it as critical,

---
So  in case slapi-nis plugin doesn't support "paged results control", it is
quite incorrect to absolutely ignore control regardless of their
"criticality". To comply with RFC2696 slapi-nis plugin shall reply
with "unsupportedCriticalExtension"
error in such cases. Am i right?


ср, 14 груд. 2016 о 18:24 Alexander Bokovoy  пише:

> On ke, 14 joulu 2016, Serhii Honchar wrote:
> >Hello,
> >
> >trying to get vSphere authenticate users using FreeIPA.
> >I've made scheme changes as recommended in howto
> >http://www.freeipa.org/page/HowTo/vsphere5_integration.
> >But then faced following issue:
> >Vsphere using "pagedResultsControl" and sets it's criticality to "True" on
> >all it's requests to LDAP server:
> >---
> >Lightweight Directory Access Protocol
> >LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX"
> >wholeSubtree
> >messageID: 2
> >protocolOp: searchRequest (3)
> >[Response In: 17]
> > *   controls: 1 item *
> >*Control *
> >*controlType: 1.2.840.113556.1.4.319
> (pagedResultsControl) *
> >*criticality: True *
> >*SearchControlValue *
> >*size: 100 *
> >*cookie:  *
> >---
> >
> >When requesting from "cn=accounts" subtree things go ok, and reply also
> >contain "pagedResultsControl" block:
> >---
> >Lightweight Directory Access Protocol
> >LDAPMessage searchResDone(2) success [1 result]
> >messageID: 2
> >protocolOp: searchResDone (5)
> >searchResDone
> >resultCode: success (0)
> >matchedDN:
> >errorMessage:
> >[Response To: 15]
> >[Time: 0.065699000 seconds]
> >  *  controls: 1 item*
> >*Control*
> >*controlType: 1.2.840.113556.1.4.319
> (pagedResultsControl)*
> >*SearchControlValue*
> >*size: 0*
> >*cookie: *
> >---
> >and vSphere accepts the results of such queries without any problem,
> except
> >the fact that there are no some required attributes in objects in this
> >subtree.
> >
> >But on same requests to "cn=compat" subtree (where all required attributes
> >added) something goest wrong, and replies doesn't contain
> >"pagedResultsControl" block (the result set itself is identical, absence
> of
> >controls block is only difference) :
> That's correct because slapi-nis plugin does not support paged results
> control for the virtual subtree.
>
> --
> / Alexander Bokovoy
>
-- 
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] FreeIPA and vSphere

[Alexander Bokovoy]

On ke, 14 joulu 2016, Serhii Honchar wrote:

Hello,

trying to get vSphere authenticate users using FreeIPA.
I've made scheme changes as recommended in howto
http://www.freeipa.org/page/HowTo/vsphere5_integration.
But then faced following issue:
Vsphere using "pagedResultsControl" and sets it's criticality to "True" on
all it's requests to LDAP server:
---
Lightweight Directory Access Protocol
   LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX"
wholeSubtree
   messageID: 2
   protocolOp: searchRequest (3)
   [Response In: 17]
*   controls: 1 item *
*Control *
*controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) *
*criticality: True *
*SearchControlValue *
*size: 100 *
*cookie:  *
---

When requesting from "cn=accounts" subtree things go ok, and reply also
contain "pagedResultsControl" block:
---
Lightweight Directory Access Protocol
   LDAPMessage searchResDone(2) success [1 result]
   messageID: 2
   protocolOp: searchResDone (5)
   searchResDone
   resultCode: success (0)
   matchedDN:
   errorMessage:
   [Response To: 15]
   [Time: 0.065699000 seconds]
 *  controls: 1 item*
*Control*
*controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)*
*SearchControlValue*
*size: 0*
*cookie: *
---
and vSphere accepts the results of such queries without any problem, except
the fact that there are no some required attributes in objects in this
subtree.

But on same requests to "cn=compat" subtree (where all required attributes
added) something goest wrong, and replies doesn't contain
"pagedResultsControl" block (the result set itself is identical, absence of
controls block is only difference) :

That's correct because slapi-nis plugin does not support paged results
control for the virtual subtree.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] FreeIPA and vSphere

[Serhii Honchar]

Hello,

trying to get vSphere authenticate users using FreeIPA.
I've made scheme changes as recommended in howto
http://www.freeipa.org/page/HowTo/vsphere5_integration.
But then faced following issue:
Vsphere using "pagedResultsControl" and sets it's criticality to "True" on
all it's requests to LDAP server:
---
Lightweight Directory Access Protocol
LDAPMessage searchRequest(2) "cn=users,cn=compat,dc=XXX,dc=XXX"
wholeSubtree
messageID: 2
protocolOp: searchRequest (3)
[Response In: 17]
 *   controls: 1 item *
*Control *
*controlType: 1.2.840.113556.1.4.319 (pagedResultsControl) *
*criticality: True *
*SearchControlValue *
*size: 100 *
*cookie:  *
---

When requesting from "cn=accounts" subtree things go ok, and reply also
contain "pagedResultsControl" block:
---
Lightweight Directory Access Protocol
LDAPMessage searchResDone(2) success [1 result]
messageID: 2
protocolOp: searchResDone (5)
searchResDone
resultCode: success (0)
matchedDN:
errorMessage:
[Response To: 15]
[Time: 0.065699000 seconds]
  *  controls: 1 item*
*Control*
*controlType: 1.2.840.113556.1.4.319 (pagedResultsControl)*
*SearchControlValue*
*size: 0*
*cookie: *
---
and vSphere accepts the results of such queries without any problem, except
the fact that there are no some required attributes in objects in this
subtree.

But on same requests to "cn=compat" subtree (where all required attributes
added) something goest wrong, and replies doesn't contain
"pagedResultsControl" block (the result set itself is identical, absence of
controls block is only difference) :
---
Lightweight Directory Access Protocol
LDAPMessage searchResDone(2) success [1 result]
messageID: 2
protocolOp: searchResDone (5)
[Response To: 15]
[Time: 0.001349000 seconds]
---

Thus vSphere doesn't accept the results of queries to "cn=compat" subtree
regardless of their results.
Such behavior also seems to be violating RFC2696 which stands:
---

If the server does not support this control, the server
   MUST return an error of unsupportedCriticalExtension if the client
   requested it as critical, otherwise the server SHOULD ignore the
   control. The remainder of this section assumes the server does not
   ignore the client's pagedResultsControl.

   Each time the server returns a set of results to the client when
   processing a search request containing the pagedResultsControl, the
   server includes the pagedResultsControl control in the
   searchResultDone message.

---

Please help me to find the answers for following questions:
1) why the replies for the requests to "cn=compat" subtree don't contain
controls block?
2) is it possible to configure ns-slapd/slapi-nis to force replies for
queries to "cn=compat" subtree either to return a unsupportedCriticalExtension
or to contain a valid control block in case when the request contains
controls with "criticality" set to "True"?
-- 
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] Free IPA Openssh client install error

[James Harrison]

In the ipaclient-install.log I see:

2016-12-14T14:58:10Z DEBUG stderr=
2016-12-14T14:58:10Z DEBUG Backing up system configuration file 
'/etc/ssh/ssh_config'
2016-12-14T14:58:10Z DEBUG Saving Index File to 
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2016-12-14T14:58:10Z INFO Configured /etc/ssh/ssh_config
2016-12-14T14:58:10Z DEBUG Backing up system configuration file 
'/etc/ssh/sshd_config'
2016-12-14T14:58:10Z DEBUG Saving Index File to 
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2016-12-14T14:58:10Z DEBUG Starting external process
2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o 
AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o 
AuthorizedKeysCommandUser=nobody
2016-12-14T14:58:10Z DEBUG Process finished, return code=1
2016-12-14T14:58:10Z DEBUG stdout=
2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration 
option: AuthorizedKeysCommand^M

2016-12-14T14:58:10Z DEBUG Starting external process
2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o 
AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o 
AuthorizedKeysCommandRunAs=nobody
2016-12-14T14:58:10Z DEBUG Process finished, return code=1
2016-12-14T14:58:10Z DEBUG stdout=
2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration 
option: AuthorizedKeysCommand^M

2016-12-14T14:58:10Z DEBUG Starting external process
2016-12-14T14:58:10Z DEBUG args=sshd -t -f /dev/null -o 
PubKeyAgent=/usr/bin/sss_ssh_authorizedkeys %u -o PubKeyAgentRunAs=nobody
2016-12-14T14:58:10Z DEBUG Process finished, return code=1
2016-12-14T14:58:10Z DEBUG stdout=
2016-12-14T14:58:10Z DEBUG stderr=command-line: line 0: Bad configuration 
option: PubKeyAgent^M

2016-12-14T14:58:10Z WARNING Installed OpenSSH server does not support 
dynamically loading authorized user keys. Public key authentication of IPA 
users will not be available.



  From: James Harrison 
 To: "freeipa-users@redhat.com"  
 Sent: Wednesday, 14 December 2016, 15:18
 Subject: Free IPA Openssh client install error
   
Hi,I installed the freeipa client on an Ubuntu Precise system (12.04)

I get the following message at the end of the install:
"Installed OpenSSH server does not support dynamically loading authorized user 
keys. Public key authentication of IPA users will not be available."

Any clues? Is there a fix?

Best regards,James Harrison


   -- 
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] Free IPA Openssh client install error

[Sumit Bose]

On Wed, Dec 14, 2016 at 03:18:52PM +, James Harrison wrote:
> Hi,I installed the freeipa client on an Ubuntu Precise system (12.04)
> 
> I get the following message at the end of the install:
> "Installed OpenSSH server does not support dynamically loading authorized 
> user keys. Public key authentication of IPA users will not be available."
> 
> Any clues? Is there a fix?

Either OpenSSH on Ubuntu 12.04 does not support the
AuthorizedKeysCommand sshd option or the checks ipa-client-install is
trying do not match.

ipa-client-install calls

sshd -t -f /dev/null -o 
AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o 
AuthorizedKeysCommandUser=nobody

to check if sshd supports the option. It also tries
'AuthorizedKeysCommand' with 'AuthorizedKeysCommandRunAs' and
'PubKeyAgent' with 'PubKeyAgentRunAs'.

Do you see related messages in /var/log/ipaclient-install.log ?

HTH

bye,
Sumit

> 
> Best regards,James Harrison

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Free IPA Openssh client install error

[James Harrison]

Hi,I installed the freeipa client on an Ubuntu Precise system (12.04)

I get the following message at the end of the install:
"Installed OpenSSH server does not support dynamically loading authorized user 
keys. Public key authentication of IPA users will not be available."

Any clues? Is there a fix?

Best regards,James Harrison
-- 
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

[Rob Crittenden]

Jim Richard wrote:
> 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 :)

No but the complete, unredacted logs were VERY helpful, thanks.

So the code looks like this in 3.0, which IIRC you are running:

try:
self.check_access()
except errors.ACIError, acierr:
self.debug("Not granted by ACI to retrieve certificate,
looking at principal")
bind_principal = getattr(context, 'principal')
if not bind_principal.startswith('host/'):
raise acierr

By default hosts aren't in the ACI that allows one to retrieve certs but
if you bind as one it is later given a pass. It would seem that is
failing, though it is also clear from the log that the client is binding
with a host principal, so I'm baffled.

I think it would probably be best to add more debug logging around these
lines to try to see what is going on, something like:

self.debug("bind_principal = %s", bind_principal)

And then later, the same aci error can be raised after checking the
hostname. I'd add in a debug log there too, to look soemthing like:

if hostname != cert.subject.common_name:#pylint: disable=E1101
self.debug('hostname %s doesn't match subject %s', hostname,
cert.subject.common_name)
raise acierr

You'd make these changes in
/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py then restart
httpd. I'd make a backup of the file first to make reverting easier.

rob

> 
> [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/wQCMAAwIAYDVR0OAQEABBYEFKDhj0rZ6mZwJfrJx3pCI12dct5WMA0GCSqG!
 SIb3DQEBCw
UAA4IBAQC/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
> 

[Freeipa-users] Replica Creation Issue

[Christian McNamara]

Hi all,

I recently inherited a FreeIPA system that I believe is running v3.0, and
I'm trying to upgrade to the latest version. Following documentation, I'm
trying to create a replica but I'm running into problems connecting to the
LDAP server. Here's the output I get when trying to prepare a replica:

$ sudo ipa-replica-prepare auth4.sshchicago.org --ip-address 172.31.31.36
Directory Manager (existing master) password:

Preparing replica for auth4.sshchicago.org from auth3.sshchicago.org
preparation of replica failed: cannot connect to u'ldaps://
auth3.sshchicago.org:

  7390': LDAP Server Down
cannot connect to u'ldaps://auth3.sshchicago.org:7390': LDAP Server Down
  File "/usr/sbin/ipa-replica-prepare", line 529, in 
main()

  File "/usr/sbin/ipa-replica-prepare", line 391, in main
update_pki_admin_password(dirman_password)

  File "/usr/sbin/ipa-replica-prepare", line 247, in
update_pki_admin_password
bind_pw=dirman_password

  File "/usr/lib/python2.6/site-packages/ipalib/backend.py", line 63, in
connect
conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
846,

   in create_connection
self.handle_errors(e)

  File "/usr/lib/python2.6/site-packages/ipaserver/plugins/ldap2.py", line
736,

   in handle_errors
error=u'LDAP Server Down')


It says that our LDAP server is down, but it's trying to connect using the
wrong port number. Our LDAP server runs on 389, not 7390, and I can't
figure out how to specify this to the prepare script.

Any ideas?
-- 
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] Failed ipa-client-install with IPA Replica

[Florence Blanc-Renaud]

On 12/14/2016 01:08 PM, beeth beeth wrote:

Thanks David. I installed both the master and replica IPA servers with
third-party certificates(Verisign), but I doubt that could be the issue,
because I had no problem to run the same ipa-client-install command on a
RHEL7 machine(of course, the --hostname used a different hostname of the
server). And I had no problem to run the ipa-client-install command with
--server= on such RHEL6 machine. So what could cause the LDAP
communication failed during the client enrollment with the replica? Is
there a way I can troubleshoot this by running some commands? So far I
did telnet to check the open ports, as well as run the ldapsearch
towards the replica. Thanks again!


On Tue, Dec 13, 2016 at 8:46 AM, David Kupka > wrote:

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 

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

[beeth beeth]

Thanks David. I installed both the master and replica IPA servers with
third-party certificates(Verisign), but I doubt that could be the issue,
because I had no problem to run the same ipa-client-install command on a
RHEL7 machine(of course, the --hostname used a different hostname of the
server). And I had no problem to run the ipa-client-install command with
--server= on such RHEL6 machine. So what could cause the LDAP
communication failed during the client enrollment with the replica? Is
there a way I can troubleshoot this by running some commands? So far I did
telnet to check the open ports, as well as run the ldapsearch towards the
replica. Thanks again!


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

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

Re: [Freeipa-users] Change in list archives accessibility

[Simo Sorce]

On Mon, 2016-12-12 at 05:04 -0500, Simo Sorce wrote:
> Dear freeipa-users,
> in an attempt to identify how the recent wave of spamming activity
> targets mailing list posters, I have temporarily disabled free access to
> the archives.
> This is not a permanent change and public access will be restored
> shortly.

Dear freeipa-users,
I am going to conclude this experiment now, public access to the list
archives is invaluable for searches.
Apologies in advance if the spam issue will resurface, we are studying a
way to deal with it w/o compromising public access for search and
archive purposes.

If you have an ideas/complaints/suggestions feel free to contact the
mailing list owners address.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa fails to start after centos 7.3 upgrade

[Brian Candler]

On 12/12/2016 19:53, Rob Verduijn wrote:

I've recently upgraded to centos 7.3.
Didn't intend to so soon but should have checked the anounce lists 
before launching my ansible update playbook.


Most of my servers came through, and mostly also the ipa server.
There were duplicate rpms and a failed rpm upgrade.
After some yum magic the rpm duplicates where gone and all the updates 
installed.


Manually running ipa-server-upgrade also seems to finish properly.

However
ipactl start keeps failing on the ntpd service.
Not a big surprise since its running chronyd.

I now start the ipa server with 'ipactl start --ignore-service-failure'

Is there a way to explain the script that it should check for chronyd 
instead of ntpd ?



Aside: I also have a use case for running without ntp.  I run freeipa 
inside an lxd container (*), so ntpd is running on the outer host, not 
in the container.


However unlike you, after upgrading to CentOS 7.3 / FreeIPA 4.4.0 inside 
the container I don't see any problem:


[root@ipa-2 ~]# ipactl stop
Stopping ipa-otpd Service
Stopping pki-tomcatd Service
Stopping ntpd Service
Stopping ipa-custodia Service
Stopping httpd Service
Stopping ipa_memcached Service
Stopping kadmin Service
Stopping krb5kdc Service
Stopping Directory Service
ipa: INFO: The ipactl command was successful
[root@ipa-2 ~]# ipactl start
Starting Directory Service
Starting krb5kdc Service
Starting kadmin Service
Starting ipa_memcached Service
Starting httpd Service
Starting ipa-custodia Service
Starting ntpd Service
Starting pki-tomcatd Service
Starting ipa-otpd Service
ipa: INFO: The ipactl command was successful
[root@ipa-2 ~]#

ntpd won't run inside the container, which is expected:

[root@ipa-2 ~]# systemctl status ntpd
● ntpd.service - Network Time Service
   Loaded: loaded (/usr/lib/systemd/system/ntpd.service; disabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Wed 2016-12-14 10:51:09 
UTC; 2min 18s ago
  Process: 1357 ExecStart=/usr/sbin/ntpd -u ntp:ntp $OPTIONS 
(code=exited, status=0/SUCCESS)

 Main PID: 1358 (code=exited, status=255)

Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 4 
eth0:1 10.0.0.149 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 5 
lo ::1 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listen normally on 6 
eth0 fe80::216:3eff:fef2:a083 UDP 123
Dec 14 10:51:08 ipa-2.int.cityfibre.com ntpd[1358]: Listening on routing 
socket on fd #23 for interface updates

Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c016 06 restart
Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c012 02 
freq_set ntpd 0.000 PPM
Dec 14 10:51:09 ipa-2.int.cityfibre.com ntpd[1358]: 0.0.0.0 c011 01 
freq_not_set
Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service: main 
process exited, code=exited, status=255/n/a
Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: Unit ntpd.service 
entered failed state.

Dec 14 10:51:09 ipa-2.int.cityfibre.com systemd[1]: ntpd.service failed.

But ipactl is not complaining, which is good. But I don't know why it 
works for me and not for you.


Anyway, I hope that for future reference this use case remains 
supported.  In a container environment like lxd or docker, you *cannot* 
run ntpd (but that doesn't mean the time isn't synced!)


Regards,

Brian.

(*) Aside: this makes snapshotting IPA a breeze.


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

[Alexander Bokovoy]

On ke, 14 joulu 2016, Florence Blanc-Renaud wrote:

On 12/13/2016 05:29 PM, jay wrote:

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

Hi Jay,

this behavior was introduced with the fix for ticket 4291 (CA not 
start during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 
[1].


I agree that the doc [2] does not explicitely mention that IPv6 is 
required, but it sort of suggests that it should be set up.

We actually require IPv6 stack on IPA masters for very long time.

There is no reason why IPv6 stack should be disabled. You may lack
addresses, even local ones, but given that IPv4 and IPv6 share the same
port space, a single API is recommended to be used in implementing
networking applications by the documentation in ipv6(7):


 IPv4 connections can be handled with the v6 API by using the
 v4-mapped-on-v6 address type; thus a program needs to support only
 this API type to support both protocols. This is handled
 transparently by the address handling functions in the C library.

 IPv4 and IPv6 share the local port space.  When you get an IPv4
 connection or packet to a IPv6 socket, its source address will be
 mapped to v6 and it will be mapped to v6.


Thus, most of IPA code actually is implemented using this approach. You
need to have IPv6 enabled in the kernel but not necessary used.

This is mentioned as a requirement in the Windows Integration guide but
it is valid for a normal IPA install as well:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Windows_Integration_Guide/index.html#trust-req-ipv6


I found an e-mail thread mentioning why IPv6 should not be disabled 
[3], and also on freeipa.org a wiki for Deployment recommendations 
[4].


I will open a documentation bug asking to add this requirement in Red 
Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and 
Policy Guide.


Flo

[1] https://fedorahosted.org/freeipa/ticket/4291
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
[3] 
https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html
[4] 
http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration


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.in
   TERNAL:
   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
   *   

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

[Florence Blanc-Renaud]

On 12/13/2016 05:29 PM, jay wrote:

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

Hi Jay,

this behavior was introduced with the fix for ticket 4291 (CA not start 
during ipa server install in pure IPv6 env) in FreeIPA 4.4.1 [1].


I agree that the doc [2] does not explicitely mention that IPv6 is 
required, but it sort of suggests that it should be set up.


I found an e-mail thread mentioning why IPv6 should not be disabled [3], 
and also on freeipa.org a wiki for Deployment recommendations [4].


I will open a documentation bug asking to add this requirement in Red 
Hat Enterprise Linux 7 Linux Domain Identity, Authentication, and Policy 
Guide.


Flo

[1] https://fedorahosted.org/freeipa/ticket/4291
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/installing-ipa.html#dns-reqs
[3] 
https://www.redhat.com/mailman/private/freeipa-users/2015-September/msg00175.html
[4] 
http://www.freeipa.org/page/Deployment_Recommendations#Active_Directory_Integration



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.in
TERNAL:
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.INT
ERNAL
*   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