Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 08/07/16 16:49, Roderick Johnstone wrote:
On 07/07/16 18:06, Roderick Johnstone wrote:
On 07/07/16 16:30, Petr Vobornik wrote:
On 07/07/2016 05:09 PM, Roderick Johnstone wrote:
On 07/07/16 15:02, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 05/07/16 11:52, Roderick Johnstone wrote:
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago
(Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2
ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some
info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL
Server
ipa: DEBUG: cert valid True for
"CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37
GMT',
'content-length': '161', 'content-type': 'application/xml',
'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server
Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
The
ipa-replica-prepare command failed, exception: RuntimeError:
Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on
both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be
located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system"
and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but
not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1
July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could
not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could
not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could
not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could
not
store certificate serial number 0x1
0.http-bio-8443-exec-6
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 07/07/16 18:06, Roderick Johnstone wrote:
On 07/07/16 16:30, Petr Vobornik wrote:
On 07/07/2016 05:09 PM, Roderick Johnstone wrote:
On 07/07/16 15:02, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 05/07/16 11:52, Roderick Johnstone wrote:
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago
(Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2
ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some
info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for
"CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37
GMT',
'content-length': '161', 'content-type': 'application/xml',
'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server
Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
The
ipa-replica-prepare command failed, exception: RuntimeError:
Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on
both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be
located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system" and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1
July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:17:28:35 BST] [3] [3] Could
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 07/07/16 16:30, Petr Vobornik wrote:
On 07/07/2016 05:09 PM, Roderick Johnstone wrote:
On 07/07/16 15:02, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 05/07/16 11:52, Roderick Johnstone wrote:
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago
(Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2
ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some
info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for
"CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37
GMT',
'content-length': '161', 'content-type': 'application/xml',
'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server
Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: RuntimeError:
Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on
both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be
located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system" and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1
July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:17:28:35 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-844
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 07/07/16 15:02, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 05/07/16 11:52, Roderick Johnstone wrote:
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago
(Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2 ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37 GMT',
'content-length': '161', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG:
File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line
171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: RuntimeError:
Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on
both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system" and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1 July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:17:28:35 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:17:56:02 BST] [3] [3] Could not
store certificate serial number 0x3
A
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 05/07/16 11:52, Roderick Johnstone wrote:
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago (Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2 ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37 GMT',
'content-length': '161', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: RuntimeError: Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system" and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1 July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:17:28:35 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:17:56:02 BST] [3] [3] Could not
store certificate serial number 0x3
At corresponding times, in the debug logs there are entries like:
Re: [Freeipa-users] ipa-replica-prepare Certificate issuance failed
On 04/07/2016 15:12, Martin Babinsky wrote:
On 07/04/2016 10:23 AM, Roderick Johnstone wrote:
Hi
I installed my first master ipa server (server1) many months ago (Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2 ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37 GMT',
'content-length': '161', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body '1Server Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: RuntimeError: Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
Hi Roderick,
try to look in the logs of the pki-ca subsystem. They should be located
in /var/log/pki/pki-tomcat/ca/ directory. Look into the "system" and
"debug" logs mainly.
Martin
Thanks for the pointers. We had looked at a lot of log files, but not
those ones!
We were running the ipa-replica-prepare during the afternoon of 1 July.
Here are the last few entries in the system log file.
0.profileChangeMonitor - [24/Jun/2016:04:45:51 BST] [8] [3] In Ldap
(bound) connection pool to host server1.example.com port 636, Cannot
connect to LDAP server. Error: netscape.ldap.LDAPException: IO Error
creating JSS SSL Socket (-1)
0.CRLIssuingPoint-MasterCRL - [01/Jul/2016:10:26:04 BST] [3] [3]
CRLIssuingPoint MasterCRL - Cannot store the CRL cache in the
internaldb. Error LDAP operation failure -
cn=MasterCRL,ou=crlIssuingPoints, ou=ca, o=ipaca
netscape.ldap.LDAPException: error result (1)
0.http-bio-8443-exec-4 - [01/Jul/2016:16:04:58 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:16:07:18 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:16:13:37 BST] [3] [3] Could not
store certificate serial number 0x3
0.http-bio-8443-exec-4 - [01/Jul/2016:17:07:01 BST] [3] [3] Could not
store certificate serial number 0x1
0.http-bio-8443-exec-6 - [01/Jul/2016:17:28:35 BST] [3] [3] Could not
store certificate serial number 0x2
0.http-bio-8443-exec-8 - [01/Jul/2016:17:56:02 BST] [3] [3] Could not
store certificate serial number 0x3
At corresponding times, in the debug logs there are entries like:
[01/Jul/2016:16:04:58][http-bio-8443-exec-4]: LD
[Freeipa-users] ipa-replica-prepare Certificate issuance failed
Hi
I installed my first master ipa server (server1) many months ago (Redhat
7.1 IIRC) and made a replica server2 without problems.
Now I'd like to bring online another replica (server3).
All servers are now on Redhat 7.2 ipa-server-4.2.0-15.el7_2.17.x86_64,
but I get the following error when I run this on server1:
server1> ipa-replica-prepare server3.example.com
Directory Manager (existing master) password:
Preparing replica for server3.example.com from server1.example.com
Creating SSL certificate for the Directory Server
Certificate issuance failed
If I repeat this on server2, my fist replica, it succeeds.
Running in debug mode on server1:
server1> ipa-replica-prepare --debug server3.example.com
gives a lot of output of which the following seems relevant (some info
has been anonymised):
Generating key. This may take a few moments...
ipa: DEBUG: request POST
https://server1.example.com:8443/ca/ee/ca/profileSubmitSSLClient
ipa: DEBUG: request body
'profileId=caIPAserviceCert_name=IPA+Installer_request=...CU24QyOEd%0A_request_type=pkcs10=true'
ipa: DEBUG: NSSConnection init server1.example.com
ipa: DEBUG: Connecting: xxx.xxx.xxx.xxx:0
ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server
ipa: DEBUG: cert valid True for "CN=server1.example.com,O=EXAMPLE.COM"
ipa: DEBUG: handshake complete, peer = xxx.xxx.xxx.xxx:8443
ipa: DEBUG: Protocol: TLS1.2
ipa: DEBUG: Cipher: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ipa: DEBUG: response status 200
ipa: DEBUG: response headers {'date': 'Fri, 01 Jul 2016 15:13:37 GMT',
'content-length': '161', 'content-type': 'application/xml', 'server':
'Apache-Coyote/1.1'}
ipa: DEBUG: response body 'standalone="no"?>1Server Internal
Error 3'
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: File
"/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in
execute
return_value = self.run()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 337, in run
self.copy_ds_certificate()
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 382, in copy_ds_certificate
self.export_certdb("dscert", passwd_fname)
File
"/usr/lib/python2.7/site-packages/ipaserver/install/ipa_replica_prepare.py",
line 589, in export_certdb
db.create_server_cert(nickname, hostname, ca_db)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 337, in create_server_cert
cdb.issue_server_cert(self.certreq_fname, self.certder_fname)
File "/usr/lib/python2.7/site-packages/ipaserver/install/certs.py",
line 418, in issue_server_cert
raise RuntimeError("Certificate issuance failed")
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: DEBUG: The
ipa-replica-prepare command failed, exception: RuntimeError: Certificate
issuance failed
ipa.ipaserver.install.ipa_replica_prepare.ReplicaPrepare: ERROR:
Certificate issuance failed
If its of relevance I did change the directory manager password on both
server1 and server2 a couple of weeks ago.
I'd appreciate some pointers to resolving this.
Thanks
Roderick Johnstone
--
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] How to unset a user's kerberos principal expiration date?
On 30/06/16 14:14, Rob Crittenden wrote: David Kupka wrote: On 29/06/16 19:05, Roderick Johnstone wrote: Hi If I set a kerberos principal for a user to expire on a given date using: ipa user-mod --principal-expiration=DATE is it possible to later remove this expiration date rather than just set it to a time far in the future? Thanks Roderick Johnstone Hello Roderick, AFAIK the only way to remove principal expiration at the time is remove krbPrincipalExpiration attribute from the user entry in DS. $ kinit admin Password for ad...@example.org $ ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: ad...@example.org SASL SSF: 56 SASL data security layer installed. dn:uid=tuser,cn=users,cn=accounts,dc=example,dc=org changetype: modify delete: krbprincipalexpiration modifying entry "uid=tuser,cn=users,cn=accounts,dc=example,dc=org" I think that it makes sense to expose this in API. Could you please file RFE (https://fedorahosted.org/freeipa/newticket)? You just need to pass in a blank value: $ ipa user-mod --principal-expiration= rob Thanks both. I can indeed confirm that setting --principal-expiration= does in fact remove the kerberos expiration date. Roderick -- 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] How to unset a user's kerberos principal expiration date?
Hi If I set a kerberos principal for a user to expire on a given date using: ipa user-mod --principal-expiration=DATE is it possible to later remove this expiration date rather than just set it to a time far in the future? Thanks Roderick Johnstone -- 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] Advice sought on monitoring freeipa status
Hi I'm trying to set up some monitoring of our freeipa installation. To start with, I'd like to know eg: 1) If replication stopped 2) Whether the ldap datatbases on replicas are inconsistent with each other. We have RHEL7 freeipa servers and RHEL6 and RHEL7 clients, all with latest distribution packages. I see a number of pages at www.ipa.org about monitoring freeipa in various ways, but I'm not sure any were actually implemented yet. Then I found this: https://github.com/peterpakos/ipa_check_consistency which looks useful but seems to require a plain text password for a privileged ldap account to be embedded in a file, which is less than ideal. So, I was wondering, as a stop gap, whether its possible to control the server that the ipa commands talk to at the command line? One could then run a cron job to iterate through the servers and compare various outputs from ipa commands. However, the ipa man page suggests the ipa command will go for either the server explicitly set in /etc/ipa/default.conf or if unavailable use those set in the DNS _SRV_ records. Maybe there is a better way to do this that I missed altogether? Roderick Johnstone -- 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] Help needed with keytabs
Hi again
After further testing, it seems like my problems were caused by the use
of the -F option on the kinit line.
Roderick
On 05/05/2016 22:31, Roderick Johnstone wrote:
Hi Mike
Thanks for sharing your setup. It looks pretty much like mine.
I just tried your kinit command syntax and then I can ipa ping
successfully. Then I tried my kinit syntax (after a kdestroy) and I can
still ipa ping successfully!
So, it does work now, but I don't know why it didn't work for me
earlier. It feels like some sort of caching problem but I think kdestroy
clears the cache.
Thanks again for your help.
Roderick
On 05/05/2016 19:47, Michael ORourke wrote:
Roderick,
Here's how we do it.
Create a service account user, for example "svc_useradm".
Then generate a keytab for the service account, and store it somewhere
secure.
ipa-getkeytab -s infrae2u01.lnx.dr.local -p svc_useradm -k
/root/svc_useradm.keytab
Now we can leverage the keytab for that user principal.
Example:
[root@infrae2u01 ~]# kdestroy
[root@infrae2u01 ~]# kinit -k -t /root/svc_useradm.keytab
svc_user...@lnx.dr.LOCAL
[root@infrae2u01 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: svc_user...@lnx.dr.LOCAL
Valid starting ExpiresService principal
05/05/16 14:24:12 05/06/16 14:24:12 krbtgt/lnx.dr.lo...@lnx.dr.LOCAL
[root@infrae2u01 ~]# ipa ping
--
IPA server version 3.0.0. API version 2.49
--
If you need to access the service account, then setup a sudo rule to
switch user to that account.
Example: "sudo su - svc_useradm"
-Mike
-Original Message-----
From: Roderick Johnstone <r...@ast.cam.ac.uk>
Sent: May 5, 2016 12:39 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Help needed with keytabs
Hi
I need to run some ipa commands in cron jobs.
The post here:
https://www.redhat.com/archives/freeipa-users/2014-March/msg00044.html
suggests I need to use a keytab file to authenticate kerberos.
I've tried the prescription there, with variations, without success.
My current testing framework is to log into the ipa client (RHEL6.7,
ipa-client-3.0.0-47.el6_7.1.x86_64) as a test user, get the keytab,
destroy the current tickets, re-establish a tgt for the user with kinit
using the keytab and try to run an ipa command. The ipa command fails
(just like in my cron jobs which use the same kinit command).
1) Log into ipa client as user test.
2) Get the keytab
$ /usr/sbin/ipa-getkeytab -s ipa.example.com -p t...@example.com -k
/home/test/test.keytab -P
New Principal Password:
Verify Principal Password:
Keytab successfully retrieved and stored in: /home/test/test.keytab
I seem to have to reset the password to what it was in this step,
otherwise it gets set to something random and the user test cannot log
into the ipa client any more.
3) Log into the ipa client as user test. Then
$ kdestroy
$ klist
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_3395_PWO4wH)
4) kinit from the keytab:
$ kinit -F t...@example.com -k -t /home/test/test.keytab
5) Check the tickets
$ klist
Ticket cache: FILE:/tmp/krb5cc_3395_PWO4wH
Default principal: t...@example.com
Valid starting ExpiresService principal
05/05/16 17:24:44 05/06/16 17:24:44 krbtgt/example@example.com
6) Run an ipa command:
$ ipa ping
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://ipa1.example.com/ipa/xml,
https://ipa2.example.com/ipa/xml
Can someone advise what I'm doing wrong in this procedure please (some
strings were changed to anonymize the setting)?
For completeness of information, the ipa servers are RHEL 7.2,
ipa-server-4.2.0-15.el7_2.6.1.x86_64.
Thanks
Roderick Johnstone
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Help needed with keytabs
Hi Mike
Thanks for sharing your setup. It looks pretty much like mine.
I just tried your kinit command syntax and then I can ipa ping
successfully. Then I tried my kinit syntax (after a kdestroy) and I can
still ipa ping successfully!
So, it does work now, but I don't know why it didn't work for me
earlier. It feels like some sort of caching problem but I think kdestroy
clears the cache.
Thanks again for your help.
Roderick
On 05/05/2016 19:47, Michael ORourke wrote:
Roderick,
Here's how we do it.
Create a service account user, for example "svc_useradm".
Then generate a keytab for the service account, and store it somewhere secure.
ipa-getkeytab -s infrae2u01.lnx.dr.local -p svc_useradm -k
/root/svc_useradm.keytab
Now we can leverage the keytab for that user principal.
Example:
[root@infrae2u01 ~]# kdestroy
[root@infrae2u01 ~]# kinit -k -t /root/svc_useradm.keytab
svc_user...@lnx.dr.LOCAL
[root@infrae2u01 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: svc_user...@lnx.dr.LOCAL
Valid starting ExpiresService principal
05/05/16 14:24:12 05/06/16 14:24:12 krbtgt/lnx.dr.lo...@lnx.dr.LOCAL
[root@infrae2u01 ~]# ipa ping
--
IPA server version 3.0.0. API version 2.49
--
If you need to access the service account, then setup a sudo rule to switch
user to that account.
Example: "sudo su - svc_useradm"
-Mike
-Original Message-----
From: Roderick Johnstone <r...@ast.cam.ac.uk>
Sent: May 5, 2016 12:39 PM
To: freeipa-users@redhat.com
Subject: [Freeipa-users] Help needed with keytabs
Hi
I need to run some ipa commands in cron jobs.
The post here:
https://www.redhat.com/archives/freeipa-users/2014-March/msg00044.html
suggests I need to use a keytab file to authenticate kerberos.
I've tried the prescription there, with variations, without success.
My current testing framework is to log into the ipa client (RHEL6.7,
ipa-client-3.0.0-47.el6_7.1.x86_64) as a test user, get the keytab,
destroy the current tickets, re-establish a tgt for the user with kinit
using the keytab and try to run an ipa command. The ipa command fails
(just like in my cron jobs which use the same kinit command).
1) Log into ipa client as user test.
2) Get the keytab
$ /usr/sbin/ipa-getkeytab -s ipa.example.com -p t...@example.com -k
/home/test/test.keytab -P
New Principal Password:
Verify Principal Password:
Keytab successfully retrieved and stored in: /home/test/test.keytab
I seem to have to reset the password to what it was in this step,
otherwise it gets set to something random and the user test cannot log
into the ipa client any more.
3) Log into the ipa client as user test. Then
$ kdestroy
$ klist
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_3395_PWO4wH)
4) kinit from the keytab:
$ kinit -F t...@example.com -k -t /home/test/test.keytab
5) Check the tickets
$ klist
Ticket cache: FILE:/tmp/krb5cc_3395_PWO4wH
Default principal: t...@example.com
Valid starting ExpiresService principal
05/05/16 17:24:44 05/06/16 17:24:44 krbtgt/example@example.com
6) Run an ipa command:
$ ipa ping
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://ipa1.example.com/ipa/xml,
https://ipa2.example.com/ipa/xml
Can someone advise what I'm doing wrong in this procedure please (some
strings were changed to anonymize the setting)?
For completeness of information, the ipa servers are RHEL 7.2,
ipa-server-4.2.0-15.el7_2.6.1.x86_64.
Thanks
Roderick Johnstone
--
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] Help needed with keytabs
Hi
I need to run some ipa commands in cron jobs.
The post here:
https://www.redhat.com/archives/freeipa-users/2014-March/msg00044.html
suggests I need to use a keytab file to authenticate kerberos.
I've tried the prescription there, with variations, without success.
My current testing framework is to log into the ipa client (RHEL6.7,
ipa-client-3.0.0-47.el6_7.1.x86_64) as a test user, get the keytab,
destroy the current tickets, re-establish a tgt for the user with kinit
using the keytab and try to run an ipa command. The ipa command fails
(just like in my cron jobs which use the same kinit command).
1) Log into ipa client as user test.
2) Get the keytab
$ /usr/sbin/ipa-getkeytab -s ipa.example.com -p t...@example.com -k
/home/test/test.keytab -P
New Principal Password:
Verify Principal Password:
Keytab successfully retrieved and stored in: /home/test/test.keytab
I seem to have to reset the password to what it was in this step,
otherwise it gets set to something random and the user test cannot log
into the ipa client any more.
3) Log into the ipa client as user test. Then
$ kdestroy
$ klist
klist: No credentials cache found (ticket cache
FILE:/tmp/krb5cc_3395_PWO4wH)
4) kinit from the keytab:
$ kinit -F t...@example.com -k -t /home/test/test.keytab
5) Check the tickets
$ klist
Ticket cache: FILE:/tmp/krb5cc_3395_PWO4wH
Default principal: t...@example.com
Valid starting ExpiresService principal
05/05/16 17:24:44 05/06/16 17:24:44 krbtgt/example@example.com
6) Run an ipa command:
$ ipa ping
ipa: ERROR: cannot connect to Gettext('any of the configured servers',
domain='ipa', localedir=None): https://ipa1.example.com/ipa/xml,
https://ipa2.example.com/ipa/xml
Can someone advise what I'm doing wrong in this procedure please (some
strings were changed to anonymize the setting)?
For completeness of information, the ipa servers are RHEL 7.2,
ipa-server-4.2.0-15.el7_2.6.1.x86_64.
Thanks
Roderick Johnstone
--
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 update changed my cipher set
On 29/04/2016 10:27, Martin Basti wrote: On 29.04.2016 11:02, Martin Basti wrote: On 28.04.2016 19:16, Roderick Johnstone wrote: Hi RHEL7 running ipa-server-4.2.0-15.el7_2.6.1.x86_64 A couple of months ago I updated /etc/dirsrv/slapd-XXX.XXX.XXX/dse.ldif to customise the cipher suite in use by freeipa (see previous thread on this list). When the update to ipa-server-4.2.0-15.el7_2.6.1.x86_64 came in on April 14 it saved my dse.ldif to dse.ldif.ipa.87160d3fec74fa3f and reverted some, but not all of, my changed settings in dse.ldif. I'd like to understand what is expected to happen to this file on a package upgrade (rpm reports that this file is not owned by any package so I guess its manipulated by a scriplet) since at least one of my changes was preserved. Also, if I need to maintain a customised cipher suite for ipa, am I required to only do yum updates of the ipa-server package by hand and manually merge back in my changes, or is there a better way? Thanks Roderick Johnstone Hello, probably IPA upgrade did this change if you need custom ciphers to be preserved, you have to put your own upgrade file (number must be higher than 20) to IPA '/usr/share/ipa/updates/' something like: $ cat 99-myciphers.update dn: cn=encryption,cn=config only:nsSSL3Ciphers: default only:allowWeakCipher: off update default value with your own required ciphers Martin I forgot to add, you have to run ipa-server-upgrade or ipa-ldap-updater /usr/share/ipa/updates/99-myciphers.update to apply changes. Martin Martin Thats the perfect solution, and works well for me. Thank you very much. I didn't see this info documented in the RHEL7 IdM Guide (apart from a reference to the directory in the list of configuration files in section 28.1) or on the freeipa wiki. Did I miss it somewhere? Thanks again. Roderick -- 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 update changed my cipher set
Hi RHEL7 running ipa-server-4.2.0-15.el7_2.6.1.x86_64 A couple of months ago I updated /etc/dirsrv/slapd-XXX.XXX.XXX/dse.ldif to customise the cipher suite in use by freeipa (see previous thread on this list). When the update to ipa-server-4.2.0-15.el7_2.6.1.x86_64 came in on April 14 it saved my dse.ldif to dse.ldif.ipa.87160d3fec74fa3f and reverted some, but not all of, my changed settings in dse.ldif. I'd like to understand what is expected to happen to this file on a package upgrade (rpm reports that this file is not owned by any package so I guess its manipulated by a scriplet) since at least one of my changes was preserved. Also, if I need to maintain a customised cipher suite for ipa, am I required to only do yum updates of the ipa-server package by hand and manually merge back in my changes, or is there a better way? Thanks Roderick Johnstone -- 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] Warning about session memcached servers from ipa-replica-manage
On 20/04/16 14:03, Rob Crittenden wrote: Roderick Johnstone wrote: Hi I'm getting the following warning on RHEL7 ipa servers (ipa-server-4.2.0-15.el7_2.6.1.x86_64). $ ipa-replica-manage list ipa: WARNING: session memcached servers not running aaa.xxx.yyy: master bbb.xxx.yyy: master Can someone advise please on what the session memcached servers are for and how to get them running, assuming they are worth having. I think this can be ignored. In order to see if there are servers running the code needs to read /var/run/ipa_memcached and lack read permissions. The warning is not particularly helpful. rob ok, thanks Rob. I'll ignore it. Roderick -- 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] Warning about session memcached servers from ipa-replica-manage
Hi I'm getting the following warning on RHEL7 ipa servers (ipa-server-4.2.0-15.el7_2.6.1.x86_64). $ ipa-replica-manage list ipa: WARNING: session memcached servers not running aaa.xxx.yyy: master bbb.xxx.yyy: master Can someone advise please on what the session memcached servers are for and how to get them running, assuming they are worth having. Thanks. Roderick Johnstone -- 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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server
On 29/01/16 12:27, Christian Heimes wrote: On 2016-01-29 13:03, Roderick Johnstone wrote: On 29/01/16 10:31, Christian Heimes wrote: On 2016-01-28 19:56, Roderick Johnstone wrote: On 28/01/16 13:39, Christian Heimes wrote: On 2016-01-28 13:51, Roderick Johnstone wrote: Hi My netapp filer is happily doing ldap over ssl lookups for account information to my RHEL 6.7 testing ipa server (ipa-server-3.0.0-47.el6_7.1.x86_64). However, when I switch the filer to use my RHEL 7.2 ipa server (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. In the dirsrv log file I see entries like this: [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot communicate securely with peer: no common encryption algorithm(s). (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa server ip address). Looking in the ldap directory for fields with cipher in the name shows a very different set of nssslenabledciphers between the two ipa-server versions. I wonder if this might be the issue? Can the ldap server tell me what ciphers its being requested to use by the filer? Yes, it looks like it is the issue. The supported cipher suites were hardened a while ago. The ticket https://fedorahosted.org/freeipa/ticket/4395 contains more information. During the TLS handshake the client sends a list of supported cipher suites to the server. The server also has a list of supported cipher suites. But the server never sends this list to the client. Instead it picks one common cipher suite (usually the most secure) from the common set of cipher suites. I don't know if you can get 389 DS to print the cipher suites. But you can snoop the ciper suites from the TLS handshake with wireshark or tshark. The handshake isnt't encrypted and can be captures on either the host or the server. # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port ldaps Christian Thanks Christian. Thats really helpful. Now I have a list of ciphers being asked for and I found that the ldap server logs which ciphers its using when it starts up file /var/log/dirsrv/slapd-/error. There isn't any overlap. I noticed that there is a setting in the dn: cn=encryption,cn=config allowWeakCipher: off and nsSSL3Ciphers: +all and found some documentation on this here: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html So, maybe I could add one (or several) of the required ciphers to nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on? Hi Roderick, I highly recommend against lowering the settings. Weak ciphers are broken and insecure ciphers, some even with NULL encryption or no authentication. At best weak ciphers may (!) protect your against a passive sniffer and incompetent attacker. They won't protect you against a serious attack. Are you able to reconfigure or update the client? Does the client even speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3? If you show me the complete handshake, I can give you further advice. The handshake output of tshark starts like this: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Christian Christian I don't think we have much control over the available client ciphers. We are running the latest Data OnTap version for our natapps so we have what we have. The netapp can do TLSv1 though. We do have firewalling on the ipa servers so that will help until one of our trusted networks is compromised! I'll send you the handshake output from tshark off list. Hi Roderick, thanks for the handshake. It looks like the application initiates a SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone makes the connection vulnerable to a man-in-the-middle attacks. You should disable SSLv2 and SSLv3 on the client app ASAP. The broken versions must be disabled on both sides. The cipher suite list is horrible, too. You don't want anything with SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name. TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode has issues with padding, because TLS does MAC-then-encrypt. Christian Christian If I wanted to enable TLS_RSA_WITH_3DES_EDE_CBC_SHA in the LDAP server can you advise the best way to do that please? I'm not quite sure how adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to nsSSL3Ciphers: +all interacts with the allowWeakCipher: off ie does adding TLS_RSA_WITH_3DES_EDE_CBC_SHA to nsSSL3Ciphers: override its rejection in allowWeakCipher: off or do I need to set allowWeakCipher: on and then explicitly exclude all the other weak ciphers in the nsSSL3Ciphers: line? Thanks Roderick -- Manage your subscription for the Freeipa-users mailing list: https://www.
Re: [Freeipa-users] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server
On 29/01/16 10:31, Christian Heimes wrote: On 2016-01-28 19:56, Roderick Johnstone wrote: On 28/01/16 13:39, Christian Heimes wrote: On 2016-01-28 13:51, Roderick Johnstone wrote: Hi My netapp filer is happily doing ldap over ssl lookups for account information to my RHEL 6.7 testing ipa server (ipa-server-3.0.0-47.el6_7.1.x86_64). However, when I switch the filer to use my RHEL 7.2 ipa server (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. In the dirsrv log file I see entries like this: [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot communicate securely with peer: no common encryption algorithm(s). (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa server ip address). Looking in the ldap directory for fields with cipher in the name shows a very different set of nssslenabledciphers between the two ipa-server versions. I wonder if this might be the issue? Can the ldap server tell me what ciphers its being requested to use by the filer? Yes, it looks like it is the issue. The supported cipher suites were hardened a while ago. The ticket https://fedorahosted.org/freeipa/ticket/4395 contains more information. During the TLS handshake the client sends a list of supported cipher suites to the server. The server also has a list of supported cipher suites. But the server never sends this list to the client. Instead it picks one common cipher suite (usually the most secure) from the common set of cipher suites. I don't know if you can get 389 DS to print the cipher suites. But you can snoop the ciper suites from the TLS handshake with wireshark or tshark. The handshake isnt't encrypted and can be captures on either the host or the server. # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port ldaps Christian Thanks Christian. Thats really helpful. Now I have a list of ciphers being asked for and I found that the ldap server logs which ciphers its using when it starts up file /var/log/dirsrv/slapd-/error. There isn't any overlap. I noticed that there is a setting in the dn: cn=encryption,cn=config allowWeakCipher: off and nsSSL3Ciphers: +all and found some documentation on this here: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html So, maybe I could add one (or several) of the required ciphers to nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on? Hi Roderick, I highly recommend against lowering the settings. Weak ciphers are broken and insecure ciphers, some even with NULL encryption or no authentication. At best weak ciphers may (!) protect your against a passive sniffer and incompetent attacker. They won't protect you against a serious attack. Are you able to reconfigure or update the client? Does the client even speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3? If you show me the complete handshake, I can give you further advice. The handshake output of tshark starts like this: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Christian Christian I don't think we have much control over the available client ciphers. We are running the latest Data OnTap version for our natapps so we have what we have. The netapp can do TLSv1 though. We do have firewalling on the ipa servers so that will help until one of our trusted networks is compromised! I'll send you the handshake output from tshark off list. Thanks Roderick -- 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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server
On 29/01/16 12:27, Christian Heimes wrote: On 2016-01-29 13:03, Roderick Johnstone wrote: On 29/01/16 10:31, Christian Heimes wrote: On 2016-01-28 19:56, Roderick Johnstone wrote: On 28/01/16 13:39, Christian Heimes wrote: On 2016-01-28 13:51, Roderick Johnstone wrote: Hi My netapp filer is happily doing ldap over ssl lookups for account information to my RHEL 6.7 testing ipa server (ipa-server-3.0.0-47.el6_7.1.x86_64). However, when I switch the filer to use my RHEL 7.2 ipa server (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. In the dirsrv log file I see entries like this: [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot communicate securely with peer: no common encryption algorithm(s). (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa server ip address). Looking in the ldap directory for fields with cipher in the name shows a very different set of nssslenabledciphers between the two ipa-server versions. I wonder if this might be the issue? Can the ldap server tell me what ciphers its being requested to use by the filer? Yes, it looks like it is the issue. The supported cipher suites were hardened a while ago. The ticket https://fedorahosted.org/freeipa/ticket/4395 contains more information. During the TLS handshake the client sends a list of supported cipher suites to the server. The server also has a list of supported cipher suites. But the server never sends this list to the client. Instead it picks one common cipher suite (usually the most secure) from the common set of cipher suites. I don't know if you can get 389 DS to print the cipher suites. But you can snoop the ciper suites from the TLS handshake with wireshark or tshark. The handshake isnt't encrypted and can be captures on either the host or the server. # tshark -Vx -Y "ssl.handshake.ciphersuites" -i YOUR_INTERFACE tcp port ldaps Christian Thanks Christian. Thats really helpful. Now I have a list of ciphers being asked for and I found that the ldap server logs which ciphers its using when it starts up file /var/log/dirsrv/slapd-/error. There isn't any overlap. I noticed that there is a setting in the dn: cn=encryption,cn=config allowWeakCipher: off and nsSSL3Ciphers: +all and found some documentation on this here: http://directory.fedoraproject.org/docs/389ds/design/nss-cipher-design.html So, maybe I could add one (or several) of the required ciphers to nsSSL3Ciphers or possibly as a last resort set allowWeakCipher: on? Hi Roderick, I highly recommend against lowering the settings. Weak ciphers are broken and insecure ciphers, some even with NULL encryption or no authentication. At best weak ciphers may (!) protect your against a passive sniffer and incompetent attacker. They won't protect you against a serious attack. Are you able to reconfigure or update the client? Does the client even speak TLS 1.0 to the server or is it restricted to SSLv2 and SSLv3? If you show me the complete handshake, I can give you further advice. The handshake output of tshark starts like this: Secure Sockets Layer SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Christian Christian I don't think we have much control over the available client ciphers. We are running the latest Data OnTap version for our natapps so we have what we have. The netapp can do TLSv1 though. We do have firewalling on the ipa servers so that will help until one of our trusted networks is compromised! I'll send you the handshake output from tshark off list. Hi Roderick, thanks for the handshake. It looks like the application initiates a SSLv2 handshake and then does a protocol upgrade to TLS 1.0. This alone makes the connection vulnerable to a man-in-the-middle attacks. You should disable SSLv2 and SSLv3 on the client app ASAP. The broken versions must be disabled on both sides. The cipher suite list is horrible, too. You don't want anything with SSL2, RC2, RC4, DES, DSS, DHE, MD5 or EXPORT in its name. TLS_RSA_WITH_3DES_EDE_CBC_SHA is the only cipher suite that is remotely good. 3DES is slow but not entirely broken as RC4. TLS/SSL in CBC mode has issues with padding, because TLS does MAC-then-encrypt. Christian Hi Christian Many thanks for the advice. I might even open a call with netapp about this. Will report back when I make some progress. Roderick -- 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] netapp unable to do ldap lookups over ssl to RHEL 7.2 ipa server
Hi My netapp filer is happily doing ldap over ssl lookups for account information to my RHEL 6.7 testing ipa server (ipa-server-3.0.0-47.el6_7.1.x86_64). However, when I switch the filer to use my RHEL 7.2 ipa server (ipa-server-4.2.0-15.el7_2.3.x86_64) the lookup doesn't work. In the dirsrv log file I see entries like this: [28/Jan/2016:09:17:45 +] conn=1338 fd=112 slot=112 SSL connection from xxx.xxx.xxx.xxx to yyy.yyy.yy.yyy [28/Jan/2016:09:17:45 +] conn=1338 op=-1 fd=112 closed - Cannot communicate securely with peer: no common encryption algorithm(s). (xxx.xxx.xxx.xxx is the filer ip address and yyy.yyy.yyy.yyy is the ipa server ip address). Looking in the ldap directory for fields with cipher in the name shows a very different set of nssslenabledciphers between the two ipa-server versions. I wonder if this might be the issue? Can the ldap server tell me what ciphers its being requested to use by the filer? Thanks Roderick Johnstone -- 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] Slow non-kerberised nfs mounts when ipa started
Hi
I'm not sure this is quite the right place to post this query, but the
problem is provoked by starting the ipa server so hopefully someone on
the list might have encountered and resolved the issue already.
This on a fully updated Redhat 7.2 system.
Once I have my ipa server started I'm finding that non-kerberised nfs4
mounts of a filesystem from a host that is not an ipa client are very
slow. Typically it takes 4-5 seconds for the mount operation to complete.
The nfs server is exporting the filesystem with the option sec=sys in
/etc/exports.
I testing the mount speed with the mount command (so no autofs involved)
and specifying the client address by ipv4 number (so no name lookups).
I can reduce the delay to 2-3 seconds by specifying -o sec=sys on the
mount line, but this too is very slow.
The following causes mounts to happen at full speed, ie less than 0.1
sec elapsed:
1) Using mount option -o vers=3 (nfs v3)
2) Turning off the nfs-secure service (stops rpc.gssd)
3) Turning off the ipa server (ipactl stop)
On my Redhat 6.7 testing ipa server the nfsv4 mounts also comlplete in
under 0.1 sec so this seems to be an RHEL7 change.
In /var/log/messages there are lots of messages like this:
gssproxy: gssproxy[790]: (OID: { 1 2 840 113554 1 2 2 }) Unspecified GSS
failure. Minor code may provide more information, No credentials cache
found
but they come out whether the nfs mounts are slow or quick.
Does anyone else see this or have any ideas on how to speed up the nfs
v4 mount on Redhat 7 when the ipa server is running?
Thanks
Roderick Johnstone
--
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] Queries on migrating nis netgroups
On 05/01/2016 17:17, Rob Crittenden wrote: Martin Kosek wrote: On 01/05/2016 04:24 PM, Rob Crittenden wrote: Martin Kosek wrote: On 01/04/2016 10:41 PM, Rob Crittenden wrote: Martin Kosek wrote: ... I anyway tried to add externalHost to the shadow hostgroup via ldapmodify as DM and it worked: # ipa netgroup-show masters Netgroup name: masters Description: ipaNetgroup masters NIS domain name: rhel72 External host: foo Member Hostgroup: masters I am still unable to add membership as admin though: # ipa netgroup-add-member masters --hosts foo2 ipa: ERROR: Insufficient access: Insufficient 'write' privilege to the 'externalHost' attribute of entry 'cn=masters,cn=ng,cn=alt,dc=rhel72'. That is the right way to do it. Unknown hosts to IPA are marked as "external" and stored separately. Just be aware that you can put anything in there so beware of typoes. This command works fine for me using IPA using ipa-server-4.2.0-15.el7 so I'm not sure where the permission bug lies. Did you try it on native netgroup (added via netgroup-add) or hostgroup shadow group? As it works for me on native netgroups, but not on shadow netgroups, where I can only add the external host with as DM. I didn't but I can reproduce it. It is probably due to this deny ACI: aci: (targetfilter = "(objectClass=mepManagedEntry)")(targetattr = "*")(version 3.0; acl "Managed netgroups cannot be modified"; deny (write) userdn = "ldap:///all;;) Ah, good catch. I was suspecting something like that, I just did not know we went that far to create deny ACI. Not very nice behavior (and deny ACIs are icky). I guess the netgroup mod commands should look to see if it is a real netgroup before trying to do a write and otherwise raise a more reasonable error. Potentially yes, although I do not see that as the most important part. I rather do not know how to solve Roderick's issue and add external hosts as part of the shadow netgroups. Currently, the only workaround is to create plain host/ghost entries for these non-ipa clients and use them in host groups. That or use real netgroups created via netgroup-add instead of hostgroups. That is the only way to have control over the advertised NIS domain in the triple anyway. rob Martin/Rob Thanks for all your analysis on this query. I had come to the conclusion that using the real netgroups was probably the way to go on this in my particular circumstances. I'm happy now that I'm not missing something obvious about the managed netgroups which would make them a better choice. Thanks again. Roderick -- 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] Queries on migrating nis netgroups
Hi I'm migrating our nis environment to freeipa 4.2.0 on Redhat 7. I need to have the netgroups set up in freeipa before migrating systems to be freeipa clients. At this point I'm trying to understand the relationship between hostgroups and netgroups and whether I should just be using ipa netgroup-add and ipa netgroup-add-member commands or whether I should be using equivalent ipa hostgroup* commands. Section 14.5.1 of the Redhat 7 Domain Identity Authentication and Policy Guide is telling me that I get a shadow netgroup for every hostgroup I create and that I can manage these netgroups with the "ipa-host-net-manage" command. I don't see the ipa-host-net-manage command. There are ipa host* commands but these don't include ipa host-net* commands. What am I missing here? Also the ipa netgroup* commands don't seem to be able to manage the shadow netgroups so I'm currently unable to manipulate my shadow netgroups to eg change the nisdomain associated with them. How do I do that? Also it looks like I can't add non-ipa clients into hostgroups so presumable not into shadow netgroups either, so maybe this is a non-starter for me. Did I understand that correctly? Thanks Roderick Johnstone -- 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] Suggestions requested for disabling an account by date
Hi I'd like to find a way to disable an account on a date that we can set in the account information. ie like the Account Availability option in Solaris Management Console or the /etc/shadow "account expiration date" concept on Linux. I couldn't obviously see in the docs or on the list how to do this in freeipa. Does anyone have any suggestions? Thanks Roderick Johnstone -- 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] Suggestions requested for disabling an account by date
On 12/11/15 13:01, Mateusz Małek wrote: Hi, W dniu 12.11.2015 o 13:35, Roderick Johnstone pisze: I'd like to find a way to disable an account on a date that we can set in the account information. ie like the Account Availability option in Solaris Management Console or the /etc/shadow "account expiration date" concept on Linux. I couldn't obviously see in the docs or on the list how to do this in freeipa. Does anyone have any suggestions? There is " Kerberos principal expiration" field in Web UI (or --principal-expiration option in CLI). When date specified there has passed, it's no longer possible to authenticate using such account. Best regards, Mateusz Małek Mateusz Thanks very much for the pointer. I'm not sure how I missed that in reading the docs. Roderick -- 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] Also attempting to integrate Solaris 10 clients with freeipa
Siggi Thanks for the reminder. I did see these a while ago - I've seen so much in so many places and became rapidly confused, because I don't have much ldap or ipa experience. I'll review your instructions and see how they fit with the Solaris 11 instructions from the mailing list that I found and try to distil a page with appropriate attributions when I've implemented something that works. Roderick On 28/04/2015 19:24, Sigbjorn Lie wrote: Hi, I wrote these bugzilla entries based on my own Solaris 10 configuration for IPA a while back. Did you try these? They include a working DUA profile (need to change server names of course) and the steps I did for configuring Solaris 10 as an IPA client. Config: https://bugzilla.redhat.com/show_bug.cgi?id=815533 Dua Profile: https://bugzilla.redhat.com/show_bug.cgi?id=815515 The attribute mapping I suggested was for auto.master only. The example dua profile above have this mapping. You may see here for a further explanation: https://www.redhat.com/archives/freeipa-users/2015-March/msg00317.html Regards, Siggi On 23 Apr 2015, at 12:59, Roderick Johnstone r...@ast.cam.ac.uk mailto:r...@ast.cam.ac.uk wrote: On 23/04/15 04:25, Rob Crittenden wrote: Roderick Johnstone wrote: On 22/04/15 14:30, Dmitri Pal wrote: On 04/21/2015 01:13 PM, Roderick Johnstone wrote: Hi I also need to integrate Solaris 10 clients with freeipa servers. I've been round many resources, eg freeipa wiki, Fedora and Red Hat manuals, various bug trackers and the freeipa-users mailing list It looks to me as if this: https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html https://www.redhat.com/archives/freeipa-users/2013-January/msg00030html might be the best guide available, although I'm not sure what changes I might need to make because I'm actually on Solaris 10 rather than 11. Can anyone advise please? There is a comment in the above post: Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. My automount maps are already called eg auto.master, auto.home on my ipa server and I'm sure I've seen a post somewhere suggesting an attributeMap can fix this issue, but I can't find it now, so maybe I am mistaken. Am I on the right track? Is anyone familiar with that fix. Thanks Roderick Johnstone We are not strong in Solaris so you really need to search user archives or wait for someone who accomplished Solaris integration to chime in here on the list. Dmitri I had gathered that from previous postings to the list and was indeed hoping that one of the Solaris experts might comment. By the way, there are various suggestions on the list of putting the best Solaris instructions on the wiki. Is that still a possibility? I'd be happy to help, but I'm not experienced with connecting Solaris to ipa yet! Roderick A few weeks back I added what I thought were the most relevant threads and pointers. The mailing list thread you refer to was converted into some documentation bugs and tickets. I referenced those at http://www.freeipa.org/page/ConfiguringUnixClients#Additional_Resources If there is anything I can improve here just let me know. Rob This page has expanded since I was searching a few weeks ago. Thanks for that. I understand that the project has no direct Solaris expertise. There are some things that could be made easier to follow and others that seem inconsistent with the mailing list thread that I found. Maybe some are just different ways of doing the same thing. I started to point some some differences in this email, but its probably best if I go through the mailing list link that I found and the web page you referenced, systematically, and list what the differences are. I'll be in touch when I have done that. In the meantime I noticed a few of small html link issues on the web page you referenced... 1) Under the section Solaris 8/9/10 / Configuring Client Authentication the link to the reference files in /var/ldap (http://www.freeipa.com/page/ConfiguringUnixClients#Client_Configuration_Files), for me, resolves to the top level Open Source Community page http://community.redhat.com/software/. I do however see the files correctly linked from the section Client Configuration Files at bottom of the page. 2) There is the same issue for the links to the nsswitch.conf and pam.conf files linked in items 2 and 4 below the above - sorry, its hard to describe well where these links are. And it would be good if the patch (Patch to update Solaris documentation) that is referred to in Solaris 8/9/10 / Additional resources could be applied to the original document and the patched document made available, or at least the information in it. Thanks Roderick rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription
Re: [Freeipa-users] Also attempting to integrate Solaris 10 clients with freeipa
On 23/04/15 14:14, Rob Crittenden wrote: Roderick Johnstone wrote: On 23/04/15 04:25, Rob Crittenden wrote: Roderick Johnstone wrote: On 22/04/15 14:30, Dmitri Pal wrote: On 04/21/2015 01:13 PM, Roderick Johnstone wrote: Hi I also need to integrate Solaris 10 clients with freeipa servers. I've been round many resources, eg freeipa wiki, Fedora and Red Hat manuals, various bug trackers and the freeipa-users mailing list. It looks to me as if this: https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html might be the best guide available, although I'm not sure what changes I might need to make because I'm actually on Solaris 10 rather than 11. Can anyone advise please? There is a comment in the above post: Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. My automount maps are already called eg auto.master, auto.home on my ipa server and I'm sure I've seen a post somewhere suggesting an attributeMap can fix this issue, but I can't find it now, so maybe I am mistaken. Am I on the right track? Is anyone familiar with that fix. Thanks Roderick Johnstone We are not strong in Solaris so you really need to search user archives or wait for someone who accomplished Solaris integration to chime in here on the list. Dmitri I had gathered that from previous postings to the list and was indeed hoping that one of the Solaris experts might comment. By the way, there are various suggestions on the list of putting the best Solaris instructions on the wiki. Is that still a possibility? I'd be happy to help, but I'm not experienced with connecting Solaris to ipa yet! Roderick A few weeks back I added what I thought were the most relevant threads and pointers. The mailing list thread you refer to was converted into some documentation bugs and tickets. I referenced those at http://www.freeipa.org/page/ConfiguringUnixClients#Additional_Resources If there is anything I can improve here just let me know. Rob This page has expanded since I was searching a few weeks ago. Thanks for that. I understand that the project has no direct Solaris expertise. There are some things that could be made easier to follow and others that seem inconsistent with the mailing list thread that I found. Maybe some are just different ways of doing the same thing. I started to point some some differences in this email, but its probably best if I go through the mailing list link that I found and the web page you referenced, systematically, and list what the differences are. I'll be in touch when I have done that. In the meantime I noticed a few of small html link issues on the web page you referenced... 1) Under the section Solaris 8/9/10 / Configuring Client Authentication the link to the reference files in /var/ldap (http://www.freeipa.com/page/ConfiguringUnixClients#Client_Configuration_Files), for me, resolves to the top level Open Source Community page http://community.redhat.com/software/. I do however see the files correctly linked from the section Client Configuration Files at bottom of the page. Fixed. 2) There is the same issue for the links to the nsswitch.conf and pam.conf files linked in items 2 and 4 below the above - sorry, its hard to describe well where these links are. Fixed, and fixed a couple of similar issues in other OS's. And it would be good if the patch (Patch to update Solaris documentation) that is referred to in Solaris 8/9/10 / Additional resources could be applied to the original document and the patched document made available, or at least the information in it. Unfortunately the upstream doc project that this is patched against was discontinued. The patch is mostly interesting for the two tickets it links to. rob Rob Sorry to be slow getting back on this. Thanks for fixing those links in the existing web page. It seems that the existing page and the mailing list thread that I found are doing slightly different things in rather different ways. The mailing list thread is more focused on using the DUAprofile and tls encrypted connections to the ldap server as well as filling in some more details of other parts of the Solaris configuration that are necessary for other features. I think it would be good to have the prescription from the mailing list also in the wiki to help others that come along. I'll not be in a position to try to join a Solaris host to my ipa server until next week at the earliest, but it is a priority for me, so when other things stop getting in the way I'll definitely be doing this. I'll document what I do following the prescription in the mailing list, for myself, and maybe this can all be made this into a new wiki page. I would be happy to lead on writing the page (and giving references where appropriate) if I had access, but realise that I might not be able to get that access. Thanks Roderick -- Manage your subscription
Re: [Freeipa-users] Also attempting to integrate Solaris 10 clients with freeipa
On 23/04/15 04:25, Rob Crittenden wrote: Roderick Johnstone wrote: On 22/04/15 14:30, Dmitri Pal wrote: On 04/21/2015 01:13 PM, Roderick Johnstone wrote: Hi I also need to integrate Solaris 10 clients with freeipa servers. I've been round many resources, eg freeipa wiki, Fedora and Red Hat manuals, various bug trackers and the freeipa-users mailing list. It looks to me as if this: https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html might be the best guide available, although I'm not sure what changes I might need to make because I'm actually on Solaris 10 rather than 11. Can anyone advise please? There is a comment in the above post: Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. My automount maps are already called eg auto.master, auto.home on my ipa server and I'm sure I've seen a post somewhere suggesting an attributeMap can fix this issue, but I can't find it now, so maybe I am mistaken. Am I on the right track? Is anyone familiar with that fix. Thanks Roderick Johnstone We are not strong in Solaris so you really need to search user archives or wait for someone who accomplished Solaris integration to chime in here on the list. Dmitri I had gathered that from previous postings to the list and was indeed hoping that one of the Solaris experts might comment. By the way, there are various suggestions on the list of putting the best Solaris instructions on the wiki. Is that still a possibility? I'd be happy to help, but I'm not experienced with connecting Solaris to ipa yet! Roderick A few weeks back I added what I thought were the most relevant threads and pointers. The mailing list thread you refer to was converted into some documentation bugs and tickets. I referenced those at http://www.freeipa.org/page/ConfiguringUnixClients#Additional_Resources If there is anything I can improve here just let me know. Rob This page has expanded since I was searching a few weeks ago. Thanks for that. I understand that the project has no direct Solaris expertise. There are some things that could be made easier to follow and others that seem inconsistent with the mailing list thread that I found. Maybe some are just different ways of doing the same thing. I started to point some some differences in this email, but its probably best if I go through the mailing list link that I found and the web page you referenced, systematically, and list what the differences are. I'll be in touch when I have done that. In the meantime I noticed a few of small html link issues on the web page you referenced... 1) Under the section Solaris 8/9/10 / Configuring Client Authentication the link to the reference files in /var/ldap (http://www.freeipa.com/page/ConfiguringUnixClients#Client_Configuration_Files), for me, resolves to the top level Open Source Community page http://community.redhat.com/software/. I do however see the files correctly linked from the section Client Configuration Files at bottom of the page. 2) There is the same issue for the links to the nsswitch.conf and pam.conf files linked in items 2 and 4 below the above - sorry, its hard to describe well where these links are. And it would be good if the patch (Patch to update Solaris documentation) that is referred to in Solaris 8/9/10 / Additional resources could be applied to the original document and the patched document made available, or at least the information in it. Thanks Roderick rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Also attempting to integrate Solaris 10 clients with freeipa
On 22/04/15 14:30, Dmitri Pal wrote: On 04/21/2015 01:13 PM, Roderick Johnstone wrote: Hi I also need to integrate Solaris 10 clients with freeipa servers. I've been round many resources, eg freeipa wiki, Fedora and Red Hat manuals, various bug trackers and the freeipa-users mailing list. It looks to me as if this: https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html might be the best guide available, although I'm not sure what changes I might need to make because I'm actually on Solaris 10 rather than 11. Can anyone advise please? There is a comment in the above post: Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. My automount maps are already called eg auto.master, auto.home on my ipa server and I'm sure I've seen a post somewhere suggesting an attributeMap can fix this issue, but I can't find it now, so maybe I am mistaken. Am I on the right track? Is anyone familiar with that fix. Thanks Roderick Johnstone We are not strong in Solaris so you really need to search user archives or wait for someone who accomplished Solaris integration to chime in here on the list. Dmitri I had gathered that from previous postings to the list and was indeed hoping that one of the Solaris experts might comment. By the way, there are various suggestions on the list of putting the best Solaris instructions on the wiki. Is that still a possibility? I'd be happy to help, but I'm not experienced with connecting Solaris to ipa yet! Roderick -- 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] Also attempting to integrate Solaris 10 clients with freeipa
Hi I also need to integrate Solaris 10 clients with freeipa servers. I've been round many resources, eg freeipa wiki, Fedora and Red Hat manuals, various bug trackers and the freeipa-users mailing list. It looks to me as if this: https://www.redhat.com/archives/freeipa-users/2013-January/msg00030.html might be the best guide available, although I'm not sure what changes I might need to make because I'm actually on Solaris 10 rather than 11. Can anyone advise please? There is a comment in the above post: Make sure that the automount maps in ipaserver is named auto_* and NOT auto.* so they are compatible with Solaris name standards. My automount maps are already called eg auto.master, auto.home on my ipa server and I'm sure I've seen a post somewhere suggesting an attributeMap can fix this issue, but I can't find it now, so maybe I am mistaken. Am I on the right track? Is anyone familiar with that fix. Thanks Roderick Johnstone -- 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] Host aliases in freeipa
On 27/02/15 20:04, Simo Sorce wrote: On Fri, 2015-02-27 at 18:59 +, Roderick Johnstone wrote: On 27/02/15 18:33, Simo Sorce wrote: On Fri, 2015-02-27 at 18:19 +, Roderick Johnstone wrote: Hi I'm trying to migrate of my NIS databases to freeipa and have got to the hosts database. In NIS a typical entry is: ipaddress canonical_name [aliases...] but I don't see how to enter the ipaddress or aliases using the ipa host-* commands. Is that possible? Maybe this is supposed to be done with the ipa dns commands, but I don't want freeipa to control the dns as we have an existing external dns infrastructure to fit into. How should I configure freeipa to do host lookups for aliases like NIS does? While NIS supports hosts maps, FreeIPA strongly encourages the use of DNS, as such we do not have direct means of providing or querying hosts maps. Simo. ok so I have to see how we can run the freeipa servers as dns servers alongside the corporate servers for our domain. I'm not sure how to proceed since I've no idea what the issues could be. Can you give me any hints or point to any docs? Is the problem that you cannot add entries to the corporate DNS server ? It is recommended to have a delegation or at least forwarding between name servers to avoid headaches. Simo. Simo Thanks for your response. We do have delegated access to update to the DNS for our domain and also run a couple of name servers ourselves. The problem is really my ignorance of what any issues might be with having ipa manage more name servers in our domain which contains many hosts that will not ipa managed. We already have a DNS infrastructure and I have seen the Benefits of integrated DNS section at http://www.freeipa.org/page/DNS. With regard to each bullet point number, my comments and queries are: 1) Our clients will have static addresses so this doesn't seem relevant in our case. 2) In my current testing setup we don't have SRV records because DNS is not managed by ipa and ipa seems to work ok. I guess we will need to add SRV records to our DNS manually when we bring on line some ipa server replicas, so there could be a win here although I wouldn't anticipate the replicas changing much, so maybe this is a one-off manual setup without ipa managing DNS. Did I understand this correctly? 3) We do not have any AD to trust, at least for the forseeable future so this does not seem relevant in our sitution. 4) I'm not sure about this one. Things seem to work at the moment. Is this again about managing the records more easily when we bring on line replica servers? Thanks for any clarification or pointers to docs or discussion that you can offer. Roderick -- 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] Host aliases in freeipa
On 27/02/15 18:33, Simo Sorce wrote: On Fri, 2015-02-27 at 18:19 +, Roderick Johnstone wrote: Hi I'm trying to migrate of my NIS databases to freeipa and have got to the hosts database. In NIS a typical entry is: ipaddress canonical_name [aliases...] but I don't see how to enter the ipaddress or aliases using the ipa host-* commands. Is that possible? Maybe this is supposed to be done with the ipa dns commands, but I don't want freeipa to control the dns as we have an existing external dns infrastructure to fit into. How should I configure freeipa to do host lookups for aliases like NIS does? While NIS supports hosts maps, FreeIPA strongly encourages the use of DNS, as such we do not have direct means of providing or querying hosts maps. Simo. ok so I have to see how we can run the freeipa servers as dns servers alongside the corporate servers for our domain. I'm not sure how to proceed since I've no idea what the issues could be. Can you give me any hints or point to any docs? Thanks Roderick -- 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] Host aliases in freeipa
Hi I'm trying to migrate of my NIS databases to freeipa and have got to the hosts database. In NIS a typical entry is: ipaddress canonical_name [aliases...] but I don't see how to enter the ipaddress or aliases using the ipa host-* commands. Is that possible? Maybe this is supposed to be done with the ipa dns commands, but I don't want freeipa to control the dns as we have an existing external dns infrastructure to fit into. How should I configure freeipa to do host lookups for aliases like NIS does? Thanks Roderick Johnstone -- 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] admin password is always expired
On 10/02/2015 14:36, Rob Crittenden wrote: Roderick Johnstone wrote: On 10/02/15 07:44, Dmitri Pal wrote: On 02/09/2015 05:35 PM, Roderick Johnstone wrote: Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin@REALM with password. kadmin.local: change_password admin@REALM Enter password for principal admin@REALM: Re-enter password for principal admin@REALM: Password for admin@REALM changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin@REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 86400 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife 90 days global_policy modify_policy: Plugin does not support the operation while modifying policy global_policy. Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin@REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind@REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone Did you set password expiration for admin manually? ok, as far as I remember, I originally changed the global_policy and then encountered the problem described above. ie I couldn't authenticate as admin using: kinit admin In trying to resolve this I found a thread that suggested to change the admin password with: ldappasswd -x -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx Maybe this was a bad move? The attribute shows that it is 1906. This makes me think that you set your expiration to a big number. However the value rolls over in 2038. So you need to make sure what you set translates to a date before 2038. I suspect I did set the expiration to too big a number originally. After I was in the always expired loop I found a number of threads mentioning this wrap around issue and I have tried a number of things to fix it, so maybe I'm just making things worse. Why are you using kdamin.local? With IPA it is not supported. Out of ignorance I guess. I'm still finding my way into all this stuff! What is the recommended way to reset an admin password in ipa when you can't authenticate as admin? There is a bunch of IPA commands that do the same. But if kinit admin won't authenticate me, how can I use the IPA commands? How can I now reset the expiration date for admin when I can't authenticate as admin? The easiest path forward is to bind as Directory Manager and change the password expiration date for the admin user. Then you can use that user to more easily modify the password policy. You want to change krbPasswordExpiration. rob Rob Thanks for your reply. Your email came while I was working on this. I seem to have achieved the same result by doing: # ldapmodify -h localhost -x -W -D cn=directory manager -f krb.ldif where I used: # ldapsearch -x -b dc=xxx,dc=xxx to find the entry for dn: cn=global_policy,cn=XXX.XXX,cn=kerberos,dc=xxx,dc=xxx I then made krb.ldif that contains: dn: cn=global_policy,cn=XXX.XXX,cn=kerberos,dc=xxx,dc=xxx changetype: modify replace: krbMaxPwdLife krbMaxPwdLife: 864000 Then I was able to reset the password with kadmin.local as before. I see that your solution is much more direct
Re: [Freeipa-users] admin password is always expired
On 10/02/15 07:44, Dmitri Pal wrote: On 02/09/2015 05:35 PM, Roderick Johnstone wrote: Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin@REALM with password. kadmin.local: change_password admin@REALM Enter password for principal admin@REALM: Re-enter password for principal admin@REALM: Password for admin@REALM changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin@REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 86400 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife 90 days global_policy modify_policy: Plugin does not support the operation while modifying policy global_policy. Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin@REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind@REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone Did you set password expiration for admin manually? ok, as far as I remember, I originally changed the global_policy and then encountered the problem described above. ie I couldn't authenticate as admin using: kinit admin In trying to resolve this I found a thread that suggested to change the admin password with: ldappasswd -x -D 'cn=directory manager' -W -S uid=admin,cn=users,cn=accounts,dc=xxx,dc=xxx Maybe this was a bad move? The attribute shows that it is 1906. This makes me think that you set your expiration to a big number. However the value rolls over in 2038. So you need to make sure what you set translates to a date before 2038. I suspect I did set the expiration to too big a number originally. After I was in the always expired loop I found a number of threads mentioning this wrap around issue and I have tried a number of things to fix it, so maybe I'm just making things worse. Why are you using kdamin.local? With IPA it is not supported. Out of ignorance I guess. I'm still finding my way into all this stuff! What is the recommended way to reset an admin password in ipa when you can't authenticate as admin? There is a bunch of IPA commands that do the same. But if kinit admin won't authenticate me, how can I use the IPA commands? How can I now reset the expiration date for admin when I can't authenticate as admin? Thanks. Roderick -- 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] admin password is always expired
Hi I seem to have locked myself out of my ipa admin account (on RHEL 6.6). This is an evaluation instance so not too big a deal, but a good learning experience. I suspect its some changes that I made to the password policy that caused this. The admin account has expired and I'm trying to reset the password like this: # kadmin.local Authenticating as principal root/admin@REALM with password. kadmin.local: change_password admin@REALM Enter password for principal admin@REALM: Re-enter password for principal admin@REALM: Password for admin@REALM changed. kadmin.local: q where REALM is my realm. Then when I try to authenticate as admin: # kinit admin Password for admin@REALM: Password expired. You must change it now. Enter new password: Enter it again: kinit: Password has expired while getting initial credentials and the password is not reset. This is what the password policy looks like at the moment: kadmin.local: get_policy global_policy Policy: global_policy Maximum password life: 86400 Minimum password life: 0 Minimum password length: 8 Minimum number of password character classes: 0 Number of old keys kept: 0 Reference count: 0 Maximum password failures before lockout: 6 Password failure count reset interval: 0 days 00:01:00 Password lockout duration: 0 days 00:10:00 I'm trying to set this back to the defaults in the hope that this allows me to reset the admin password properly, but I'm getting eg: kadmin.local: modify_policy -maxlife 90 days global_policy modify_policy: Plugin does not support the operation while modifying policy global_policy. Am I on the right track to fixing the admin password problem? What am I doing wrong in trying to repair the password policy? Actually when I do the following it looks strange that Policy is set to none, but maybe this is a red herring: kadmin.local: get_principal admin Principal: admin@REALM Expiration date: [never] Last password change: Mon Feb 09 18:28:09 GMT 2015 Password expiration date: Tue May 22 11:59:53 GMT 1906 Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Mon Feb 09 18:28:09 GMT 2015 (kadmind@REALM) Last successful authentication: Mon Feb 09 18:27:00 GMT 2015 Last failed authentication: Mon Feb 09 18:25:24 GMT 2015 Failed password attempts: 0 Number of keys: 4 Key: vno 16, aes256-cts-hmac-sha1-96, Version 5 Key: vno 16, aes128-cts-hmac-sha1-96, Version 5 Key: vno 16, des3-cbc-sha1, Version 5 Key: vno 16, arcfour-hmac, Version 5 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Thanks for any help in diagnosing this issue or fixing it. Roderick Johnstone -- 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] netgroups not working for exports in freeipa - SOLVED
On 29/01/15 21:43, Roderick Johnstone wrote: On 29/01/2015 17:32, Jakub Hrozek wrote: On Wed, Jan 28, 2015 at 01:57:28PM +, Roderick Johnstone wrote: On 28/01/15 10:57, Jakub Hrozek wrote: On Tue, Jan 27, 2015 at 10:03:37PM +, Roderick Johnstone wrote: Hi I'm migrating from a legacy NIS setup to ipa. I have a number of NIS netgroups (of hosts) that are being used to export (non-kerberos) nfs shares to which I would like to migrate to ipa. I've create a new netgroup in ipa (for testing) and added some hosts to it (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping that when exporting an nfs share using the @netgroup syntax in /etc/exports that the netgroup will be looked up in ipa and the share will be exported to the hosts in the netgroup. /etc/nsswitch.conf has a line: netgroup: files nis sss /etc/exports has a line: /var/tmp/testexport @rmjnetgroup1(ro) I haven't, so far, been able to mount the exported share on a client so I'm wondering if this setup would be expected to work? What is confusing to me is that the section in the Redhat 6 Identity Management guide on netgroups also has information on running the NIS listener plugin so I'm wondering if perhaps this only works when running the nis listener. I'm trying to avoid that. I'd welcome any clarification on how to do non-kerberised nfs exports to groups of hosts. Does getent netgroup rmjnetgroup1 show the hosts you'd expect? Indeed it does. The individual triples listed for the netgroup contain entries like: (host,-,domain) where host is a fully qualified hostname which is dns resolvable. (For info if I do ypcat on one of my NIS netgroups I get a triple like this: (host,,) where host is the fully qualified host name, and nothing in the domain field. I've actually tried two netgroups with different domains set. The first one (rmjnetgroup) I made without specifying the --nisdomain option to ipa netgroup-add and domain in the output above shows as my dns domain (which is a lower case version of my kerberos realm). I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked that I could mount the shares when I exported explicitly to the fully qualified host name, and that worked ok. So, thinking that the problem was with the domain name I made a new netgroup (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the proper name for our nis domain as shown with the domainname command. I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. Roderick Thank you for your reply, then we know the SSSD's netgroup handling is correct. To be honest, we're getting a bit out of my comfort zone into the NFS area. Maybe Roland (CC) knows how to debug the issue further? Thanks for your interest Jakub. Just to round this thread out I did get the exporting to netgroups defined in ipa working. My problems were, I think, related to reverse name lookups resolving to short hostnames coming from /etc/hosts rather than FQDN names that were being used in /etc/exports (as well as some other things). Interestingly, the setting of the nis domain name by the domainname command on the nfs server doesn't seem to have to match the nisdomain setting for the netgroup for the export to work. In further testing using a netgroup in /etc/hosts.allow to control ssh access like this: sshd : @rmjnetgroup : ALLOW ALL : ALL : DENY it seems that the nis domain name set with the domainname command must match the nis domain set in the netgroup in IdM or else access is not allowed. Hoping this might be of use to someone else one day. Roderick -- 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] netgroups not working for exports in freeipa
On 29/01/2015 17:32, Jakub Hrozek wrote: On Wed, Jan 28, 2015 at 01:57:28PM +, Roderick Johnstone wrote: On 28/01/15 10:57, Jakub Hrozek wrote: On Tue, Jan 27, 2015 at 10:03:37PM +, Roderick Johnstone wrote: Hi I'm migrating from a legacy NIS setup to ipa. I have a number of NIS netgroups (of hosts) that are being used to export (non-kerberos) nfs shares to which I would like to migrate to ipa. I've create a new netgroup in ipa (for testing) and added some hosts to it (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping that when exporting an nfs share using the @netgroup syntax in /etc/exports that the netgroup will be looked up in ipa and the share will be exported to the hosts in the netgroup. /etc/nsswitch.conf has a line: netgroup: files nis sss /etc/exports has a line: /var/tmp/testexport @rmjnetgroup1(ro) I haven't, so far, been able to mount the exported share on a client so I'm wondering if this setup would be expected to work? What is confusing to me is that the section in the Redhat 6 Identity Management guide on netgroups also has information on running the NIS listener plugin so I'm wondering if perhaps this only works when running the nis listener. I'm trying to avoid that. I'd welcome any clarification on how to do non-kerberised nfs exports to groups of hosts. Does getent netgroup rmjnetgroup1 show the hosts you'd expect? Indeed it does. The individual triples listed for the netgroup contain entries like: (host,-,domain) where host is a fully qualified hostname which is dns resolvable. (For info if I do ypcat on one of my NIS netgroups I get a triple like this: (host,,) where host is the fully qualified host name, and nothing in the domain field. I've actually tried two netgroups with different domains set. The first one (rmjnetgroup) I made without specifying the --nisdomain option to ipa netgroup-add and domain in the output above shows as my dns domain (which is a lower case version of my kerberos realm). I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked that I could mount the shares when I exported explicitly to the fully qualified host name, and that worked ok. So, thinking that the problem was with the domain name I made a new netgroup (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the proper name for our nis domain as shown with the domainname command. I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. Roderick Thank you for your reply, then we know the SSSD's netgroup handling is correct. To be honest, we're getting a bit out of my comfort zone into the NFS area. Maybe Roland (CC) knows how to debug the issue further? Thanks for your interest Jakub. -- 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] netgroups not working for exports in freeipa
On 28/01/15 10:57, Jakub Hrozek wrote: On Tue, Jan 27, 2015 at 10:03:37PM +, Roderick Johnstone wrote: Hi I'm migrating from a legacy NIS setup to ipa. I have a number of NIS netgroups (of hosts) that are being used to export (non-kerberos) nfs shares to which I would like to migrate to ipa. I've create a new netgroup in ipa (for testing) and added some hosts to it (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping that when exporting an nfs share using the @netgroup syntax in /etc/exports that the netgroup will be looked up in ipa and the share will be exported to the hosts in the netgroup. /etc/nsswitch.conf has a line: netgroup: files nis sss /etc/exports has a line: /var/tmp/testexport @rmjnetgroup1(ro) I haven't, so far, been able to mount the exported share on a client so I'm wondering if this setup would be expected to work? What is confusing to me is that the section in the Redhat 6 Identity Management guide on netgroups also has information on running the NIS listener plugin so I'm wondering if perhaps this only works when running the nis listener. I'm trying to avoid that. I'd welcome any clarification on how to do non-kerberised nfs exports to groups of hosts. Does getent netgroup rmjnetgroup1 show the hosts you'd expect? Indeed it does. The individual triples listed for the netgroup contain entries like: (host,-,domain) where host is a fully qualified hostname which is dns resolvable. (For info if I do ypcat on one of my NIS netgroups I get a triple like this: (host,,) where host is the fully qualified host name, and nothing in the domain field. I've actually tried two netgroups with different domains set. The first one (rmjnetgroup) I made without specifying the --nisdomain option to ipa netgroup-add and domain in the output above shows as my dns domain (which is a lower case version of my kerberos realm). I couldn't mount nfs shares when exporting to @rmjnetgroup. I checked that I could mount the shares when I exported explicitly to the fully qualified host name, and that worked ok. So, thinking that the problem was with the domain name I made a new netgroup (rmjnetgroup1) with the option --nisdomain=xxx where xxx is the proper name for our nis domain as shown with the domainname command. I couldn't mount nfs shares when exporting to @rmjnetgroup1 either. Roderick -- 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] netgroups not working for exports in freeipa
Hi I'm migrating from a legacy NIS setup to ipa. I have a number of NIS netgroups (of hosts) that are being used to export (non-kerberos) nfs shares to which I would like to migrate to ipa. I've create a new netgroup in ipa (for testing) and added some hosts to it (using ipa netgroup-add and ipa netgroup-add-member). I'm hoping that when exporting an nfs share using the @netgroup syntax in /etc/exports that the netgroup will be looked up in ipa and the share will be exported to the hosts in the netgroup. /etc/nsswitch.conf has a line: netgroup: files nis sss /etc/exports has a line: /var/tmp/testexport @rmjnetgroup1(ro) I haven't, so far, been able to mount the exported share on a client so I'm wondering if this setup would be expected to work? What is confusing to me is that the section in the Redhat 6 Identity Management guide on netgroups also has information on running the NIS listener plugin so I'm wondering if perhaps this only works when running the nis listener. I'm trying to avoid that. I'd welcome any clarification on how to do non-kerberised nfs exports to groups of hosts. Thanks. Roderick Johnstone -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem migrating passwords fro NIS to IdM
On 19/11/14 15:00, Rob Crittenden wrote:
Rob Crittenden wrote:
Roderick Johnstone wrote:
On 19/11/2014 08:33, Roderick Johnstone wrote:
On 18/11/2014 22:58, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 18/11/2014 22:19, Dmitri Pal wrote:
On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber=
--uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash
--setattr userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file
with the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate
the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong
here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[fo_set_port_status] (0x0400): Marking port 0 of duplicate server
'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos
password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
Did you enable migration mode on the IPA server?
Yes, I ran:
ipa config-mod --enable-migration=true
on the IPA server.
Roderick
The has name probably needs to match something in cn=Password Storage
Schemes,cn=plugins,cn=config.
I'd try either {SHA512} or {SSHA512} and see if one of those works
better.
rob
Rob
I had wondered about the specification of the password hash type.
I chose SHA-512 as it seemed to be suggested in the
passwordStorageScheme attribute described in Table 14.1 of the Redhat
Directory Server Admin Guide,
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html.
But now I come to re-read that doc it suggests perhaps that SHA covers
all the SHA- variants, so I'll give it another go using {SHA}xxx as
the userpassword specification.
I have also seen the userpassword attribute referred to in other places
as userPassword and wondered whether the attribute name is case
sensitive. Do you know?
Thanks for your input.
Roderick
Rob
I just tried with --setattr userpassword='{SHA}xxx' but I get the
same result:
[simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no
errmsg set
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
I'm wondering if its something to do with the quoting. The hashed
password contains $ and there are the {} around the SHA so I'm using
strong single quotes to prevent anything following the $ being
interpreted as a variable, I hope. Maybe this is a ref herring.
I think your quoting is correct.
I've only used this method with crypt passwords. I guess theoretically
it should work with other crypt(3) schemes but I've never tried. There
could be some 389-ds-specific gotchas.
Crypt defines the storage as $id$salt$encrypted so perhaps strip out the
$id$ part since that is being defined by {SHA}, but I'm really only
guessing. The 389-ds guys may know.
LDAP attributes are not case sensitive.
Ok, this question was bugging me so I took a second to look into it.
The trick is to use CRYPT and not be too clever about knowing the scheme
the password is stored in.
This worked for me:
# grep myuser /etc/shadow
$ ipa user-add --first=test --last=user --setattr
userpassword='{CRYPT}$6
Re: [Freeipa-users] Problem migrating passwords fro NIS to IdM
On 18/11/2014 22:56, Jakub Hrozek wrote:
On 18 Nov 2014, at 23:23, Roderick Johnstone r...@ast.cam.ac.uk wrote:
On 18/11/2014 22:19, Dmitri Pal wrote:
On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber= --uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash
--setattr userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file
with the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[fo_set_port_status] (0x0400): Marking port 0 of duplicate server
'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
Did you enable migration mode on the IPA server?
Yes, I ran:
ipa config-mod --enable-migration=true
on the IPA server.
Roderick
Sorry, I missed this thread involved SSSD logs.
Normally, error 49 (Invalid credentials) means really a wrong password. Are you
sure the password was not mistyped (different keyboard layout or caps lock
perhaps) ?
Definitely not mistyped. I have tried lots of times.
Also tried typing the password in as username to check that each
character echos as expected, so pretty sure its not key layout issue.
Did you try the web UI migration?
Not yet. I'll see if I can find some docs on how to do that.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem migrating passwords fro NIS to IdM
On 18/11/2014 22:58, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 18/11/2014 22:19, Dmitri Pal wrote:
On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber= --uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash
--setattr userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file
with the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[fo_set_port_status] (0x0400): Marking port 0 of duplicate server
'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
Did you enable migration mode on the IPA server?
Yes, I ran:
ipa config-mod --enable-migration=true
on the IPA server.
Roderick
The has name probably needs to match something in cn=Password Storage
Schemes,cn=plugins,cn=config.
I'd try either {SHA512} or {SSHA512} and see if one of those works better.
rob
Rob
I had wondered about the specification of the password hash type.
I chose SHA-512 as it seemed to be suggested in the
passwordStorageScheme attribute described in Table 14.1 of the Redhat
Directory Server Admin Guide,
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html.
But now I come to re-read that doc it suggests perhaps that SHA covers
all the SHA- variants, so I'll give it another go using {SHA}xxx as
the userpassword specification.
I have also seen the userpassword attribute referred to in other places
as userPassword and wondered whether the attribute name is case
sensitive. Do you know?
Thanks for your input.
Roderick
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem migrating passwords fro NIS to IdM
On 19/11/2014 08:33, Roderick Johnstone wrote:
On 18/11/2014 22:58, Rob Crittenden wrote:
Roderick Johnstone wrote:
On 18/11/2014 22:19, Dmitri Pal wrote:
On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber= --uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash
--setattr userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file
with the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate
the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[fo_set_port_status] (0x0400): Marking port 0 of duplicate server
'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
Did you enable migration mode on the IPA server?
Yes, I ran:
ipa config-mod --enable-migration=true
on the IPA server.
Roderick
The has name probably needs to match something in cn=Password Storage
Schemes,cn=plugins,cn=config.
I'd try either {SHA512} or {SSHA512} and see if one of those works
better.
rob
Rob
I had wondered about the specification of the password hash type.
I chose SHA-512 as it seemed to be suggested in the
passwordStorageScheme attribute described in Table 14.1 of the Redhat
Directory Server Admin Guide,
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html-single/Administration_Guide/index.html.
But now I come to re-read that doc it suggests perhaps that SHA covers
all the SHA- variants, so I'll give it another go using {SHA}xxx as
the userpassword specification.
I have also seen the userpassword attribute referred to in other places
as userPassword and wondered whether the attribute name is case
sensitive. Do you know?
Thanks for your input.
Roderick
Rob
I just tried with --setattr userpassword='{SHA}xxx' but I get the
same result:
[simple_bind_done] (0x0400): Bind result: Invalid credentials(49), no
errmsg set
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
I'm wondering if its something to do with the quoting. The hashed
password contains $ and there are the {} around the SHA so I'm using
strong single quotes to prevent anything following the $ being
interpreted as a variable, I hope. Maybe this is a ref herring.
Roderick
Roderick
--
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] Problem migrating passwords fro NIS to IdM
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber= --uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash --setattr
userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file with
the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx' as
'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [fo_set_port_status]
(0x0400): Marking port 0 of duplicate server 'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [ipa_auth_ldap_done]
(0x0080): LDAP authentication failed, Password migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Problem migrating passwords fro NIS to IdM
On 18/11/2014 22:19, Dmitri Pal wrote:
On 11/18/2014 12:57 PM, Roderick Johnstone wrote:
Hi
I'm trying to migrate some nis accounts to RHEL 6 IdM while still
keeping the original passwords.
I followed the instructions at:
http://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords
The passwords are in SHA-512 format and I have been testing the
migration with commands like this (generated via a script from my nis
passwd file) on my IdM server:
$ ipa user-add xxx --first=NIS --last=USER --gidnumber= --uid=
'--gecos=test account' --homedir=/home/ --shell=/bin/bash
--setattr userpassword='{SHA-512}xxx'
where the xxx is the hashed password from the NIS password file
with the leading $6$ stripped off.
Then I remove nis from the passwd: line in /etc/nsswitch.conf so I'm
left with:
passwd: files sss
and the account that I migrated cannot log in.
From the sssd log file (below) it looks like its trying to migrate the
password but failing with an LDAP authentication failure.
I'd appreciate any pointers to how to find out whats going wrong here.
Accounts which I created manually in the web gui are working ok.
Thanks
Roderick Johnstone
Part of sssd log file
=
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[set_server_common_status] (0x0100): Marking server 'xxx.xxx.xxx.xxx'
as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[fo_set_port_status] (0x0400): Marking port 0 of duplicate server
'xxx.xxx.xxx.xxx' as 'working'
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_migration_flag_connect_done] (0x0400): Assuming Kerberos password
is missing, starting password migration.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_send]
(0x0100): Executing simple bind as:
uid=xxx,cn=users,cn=accounts,dc=xxx,dc=xxx,dc=xxx,dc=xxx
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]] [simple_bind_done]
(0x0400): Bind result: Invalid credentials(49), no errmsg set
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[ipa_auth_ldap_done] (0x0080): LDAP authentication failed, Password
migration not possible.
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 8, NULL)
[Success]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sending result [8][xxx.xxx.xxx]
(Tue Nov 18 10:47:22 2014) [sssd[be[xxx.xxx.xxx]]]
[be_pam_handler_callback] (0x0100): Sent result [8][xxx.xxx.xxx]
Did you enable migration mode on the IPA server?
Yes, I ran:
ipa config-mod --enable-migration=true
on the IPA server.
Roderick
--
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
