[Freeipa-users] A question related the passwords in the ldap
Hello ! I'm running ipa 3.0.0.47 and I have a question related to the password stored in the ldap. I was wondering if the users password were natively encrypted ? if yes, do you know by which mechanism ? Thank you in advance for your help. BR. Bahan -- 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 (directory service) Crash several times a day
well, this does not have more information:
#0 0x7efe7167c4c0 in ipapwd_keyset_free () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#1 0x7efe7167c742 in ipapwd_encrypt_encode_key () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#2 0x7efe7167c9c8 in ipapwd_gen_hashes () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#3 0x7efe7167c0a7 in ipapwd_SetPassword () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#4 0x7efe7167e458 in ipapwd_pre_bind () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
and it looks like a bug in the ipapwd plugin, we would have to reproduce
and work on a fix. I don't see any immediate relief unless you cannot
prevent clients from using password containing arbitrar octets.
Please open a ticket to get this worked on:
https://fedorahosted.org/freeipa/newticket
Ludwig
On 07/05/2016 12:07 AM, Omar AKHAM wrote:
Ok, here is a new core file : http://pastebin.com/2cJQymHd
Best regards
On 2016-07-04 09:39, Ludwig Krispenz wrote:
On 07/03/2016 03:04 PM, Omar AKHAM wrote:
Where can i find core file of ipa-server?
you still need to look for the core file of slapd, but IPA deploys
plugins for slapd and that is why you need the debuginfo for
ipa-server for a better analysis of the slapd core.
On 2016-07-01 13:29, Ludwig Krispenz wrote:
please keep the discussion on the mailing list
On 07/01/2016 01:17 PM, Omar AKHAM wrote:
Which package to install ? ipa-debuginfo?
yes
2 other crashes last night, with a different user bind this time :
rawdn = 0x7f620003a200
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
dn = 0x7f62000238b0
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
saslmech = 0x0
cred = {bv_len = 9, bv_val = 0x7f6200034af0
"nw_PA\250\063\065\067"}
be = 0x7f6254941c20
ber_rc =
rc = 0
sdn = 0x7f62000313f0
bind_sdn_in_pb = 1
referral = 0x0
errorbuf = '\000' ...
supported =
pmech =
authtypebuf =
"\000\000\000\000\000\000\000\000\370\030\002\000b\177\000\000\360\030\002\000b\177\000\000\320\030\002\000b\177\000\000\001\000
\000\000\000\000\000\000\250\311\377+b\177\000\000\320\352\377+b\177\000\000\200\376\002\000b\177\000\000\262\202\211Rb\177\000\000\260\311\377+b\177\
000\000\000\000\000\000\000\000\000\000&\272\200Rb\177\000\000\000\000\000\000\000\000\000\000<\224\204Rb\177\000\000\260\311\377+b\177\000\000\000\00
0\000\000\000\000\000\000\210\311\377+b\177\000\000\250\311\377+b\177",
'\000' , "\002\000\000\000
\305\363Tb\177\000\000\377\377\37
7\377\377\377\377\377\320\030\002\000b\177\000\000\000\000\000\000\000\000\000\000~a\003\000b\177",
'\000'
bind_target_entry = 0x0
On 2016-06-30 18:16, Ludwig Krispenz wrote:
On 06/30/2016 05:54 PM, d...@mdfive.dz wrote:
The crash is random, sometimes the user binds without probleme,
sometimes it bind and there is the error message of ipa plugin
without dirsrv crash. But when it crashes, this user's bind is
found in the new generated core file!
ok, so the user might try or use different passwords. it could be
helpful if you can install the debuginfo for the ipa-server package
and get a new stack. Please post it to teh list, you can X the
credentials in the core, although I think they will not be proper
credentials.
Ludwig
On 2016-06-30 14:50, Ludwig Krispenz wrote:
On 06/30/2016 02:45 PM, Ludwig Krispenz wrote:
On 06/30/2016 02:27 PM, d...@mdfive.dz wrote:
Hi,
Please find strace on a core file : http://pastebin.com/v9cUzau4
the crash is in an IPA plugin, ipa_pwd_extop,
to get a better stack you would have to install also the
debuginfo for ipa-server.
but tje stack matches the error messages you have seen
[30/Jun/2016:09:35:19 +0100] ipapwd_encrypt_encode_key - [file
encoding.c, line 171]: generating kerberos keys failed [Invalid
argument]
[30/Jun/2016:09:35:19 +0100] ipapwd_gen_hashes - [file
encoding.c,
line 225]: key encryption/encoding failed
they are from the function sin the call stack.
Looks like the user has a password with a \351 char:
cred = {bv_len = 15, bv_val = 0x7fc7880013a0 "d\351sertification"}
does the crash always happen with a bind from this user ?
and then someone familiar with this plugin should look into it
Regards
On 2016-06-30 12:13, Ludwig Krispenz wrote:
can you get a core file ?
http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes
On 06/30/2016 11:28 AM, d...@mdfive.dz wrote:
Hi,
The Directory Services crashes several times a day. It's
installed on CentOS 7 VM :
Installed Packages
Name: ipa-server
Arch: x86_64
Version : 4.2.0
# ipactl status
Directory Service: STOPPED
krb5kdc Service: RUNNING
kadmin Service: RUNNING
ipa_memcached Service: RUNNING
httpd Service: RUNNING
pki-tomcatd Service: RUNNING
Re: [Freeipa-users] FreeIPA (directory service) Crash several times a day
OK thanks. Ticket URL : https://fedorahosted.org/freeipa/ticket/6030
On 2016-07-05 10:51, Ludwig Krispenz wrote:
well, this does not have more information:
#0 0x7efe7167c4c0 in ipapwd_keyset_free () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#1 0x7efe7167c742 in ipapwd_encrypt_encode_key () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#2 0x7efe7167c9c8 in ipapwd_gen_hashes () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#3 0x7efe7167c0a7 in ipapwd_SetPassword () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#4 0x7efe7167e458 in ipapwd_pre_bind () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
and it looks like a bug in the ipapwd plugin, we would have to
reproduce and work on a fix. I don't see any immediate relief unless
you cannot prevent clients from using password containing arbitrar
octets.
Please open a ticket to get this worked on:
https://fedorahosted.org/freeipa/newticket
Ludwig
On 07/05/2016 12:07 AM, Omar AKHAM wrote:
Ok, here is a new core file : http://pastebin.com/2cJQymHd
Best regards
On 2016-07-04 09:39, Ludwig Krispenz wrote:
On 07/03/2016 03:04 PM, Omar AKHAM wrote:
Where can i find core file of ipa-server?
you still need to look for the core file of slapd, but IPA deploys
plugins for slapd and that is why you need the debuginfo for
ipa-server for a better analysis of the slapd core.
On 2016-07-01 13:29, Ludwig Krispenz wrote:
please keep the discussion on the mailing list
On 07/01/2016 01:17 PM, Omar AKHAM wrote:
Which package to install ? ipa-debuginfo?
yes
2 other crashes last night, with a different user bind this time :
rawdn = 0x7f620003a200
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
dn = 0x7f62000238b0
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
saslmech = 0x0
cred = {bv_len = 9, bv_val = 0x7f6200034af0
"nw_PA\250\063\065\067"}
be = 0x7f6254941c20
ber_rc =
rc = 0
sdn = 0x7f62000313f0
bind_sdn_in_pb = 1
referral = 0x0
errorbuf = '\000' ...
supported =
pmech =
authtypebuf =
"\000\000\000\000\000\000\000\000\370\030\002\000b\177\000\000\360\030\002\000b\177\000\000\320\030\002\000b\177\000\000\001\000
\000\000\000\000\000\000\250\311\377+b\177\000\000\320\352\377+b\177\000\000\200\376\002\000b\177\000\000\262\202\211Rb\177\000\000\260\311\377+b\177\
000\000\000\000\000\000\000\000\000\000&\272\200Rb\177\000\000\000\000\000\000\000\000\000\000<\224\204Rb\177\000\000\260\311\377+b\177\000\000\000\00
0\000\000\000\000\000\000\210\311\377+b\177\000\000\250\311\377+b\177",
'\000' , "\002\000\000\000
\305\363Tb\177\000\000\377\377\37
7\377\377\377\377\377\320\030\002\000b\177\000\000\000\000\000\000\000\000\000\000~a\003\000b\177",
'\000'
bind_target_entry = 0x0
On 2016-06-30 18:16, Ludwig Krispenz wrote:
On 06/30/2016 05:54 PM, d...@mdfive.dz wrote:
The crash is random, sometimes the user binds without probleme,
sometimes it bind and there is the error message of ipa plugin
without dirsrv crash. But when it crashes, this user's bind is
found in the new generated core file!
ok, so the user might try or use different passwords. it could be
helpful if you can install the debuginfo for the ipa-server
package
and get a new stack. Please post it to teh list, you can X
the
credentials in the core, although I think they will not be proper
credentials.
Ludwig
On 2016-06-30 14:50, Ludwig Krispenz wrote:
On 06/30/2016 02:45 PM, Ludwig Krispenz wrote:
On 06/30/2016 02:27 PM, d...@mdfive.dz wrote:
Hi,
Please find strace on a core file :
http://pastebin.com/v9cUzau4
the crash is in an IPA plugin, ipa_pwd_extop,
to get a better stack you would have to install also the
debuginfo for ipa-server.
but tje stack matches the error messages you have seen
[30/Jun/2016:09:35:19 +0100] ipapwd_encrypt_encode_key - [file
encoding.c, line 171]: generating kerberos keys failed [Invalid
argument]
[30/Jun/2016:09:35:19 +0100] ipapwd_gen_hashes - [file
encoding.c,
line 225]: key encryption/encoding failed
they are from the function sin the call stack.
Looks like the user has a password with a \351 char:
cred = {bv_len = 15, bv_val = 0x7fc7880013a0
"d\351sertification"}
does the crash always happen with a bind from this user ?
and then someone familiar with this plugin should look into it
Regards
On 2016-06-30 12:13, Ludwig Krispenz wrote:
can you get a core file ?
http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes
On 06/30/2016 11:28 AM, d...@mdfive.dz wrote:
Hi,
The Directory Services crashes several times a day. It's
installed on CentOS 7 VM :
Installed Packages
Name: ipa-server
Arch: x86_64
Version : 4.2.0
# ipactl status
Directory Service: STOPPED
krb5kdc Service: RUNNING
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&requestor_name=IPA+Installer&cert_request=...CU24QyOEd%0A&cert_request_type=pkcs10&xmlOutput=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]: LDAP operation failure -
cn=1,ou=certificateRepository, ou=ca, o=ipaca
netscape.ldap.LDAP
Re: [Freeipa-users] A question related the passwords in the ldap
Hi Bahan, the user passwords stored in LDAP follow the password policy configured in the LDAP server, which defines password syntax requirements as well as the password encryption algorithm. You can find more information in RedHat Directory Server Administration Guide, in the section Managing the Password Policy: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/User_Account_Management.html#User_Account_Management-Managing_the_Password_Policy By default, the password storage scheme is SSHA. This means that when a user entry is created with a password, the directory server encrypts the password using SSHA before actually storing it in the user entry. I hope this answers your question, Flo. On 07/05/2016 09:40 AM, bahan w wrote: Hello ! I'm running ipa 3.0.0.47 and I have a question related to the password stored in the ldap. I was wondering if the users password were natively encrypted ? if yes, do you know by which mechanism ? Thank you in advance for your help. BR. Bahan -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Freeipa and sudo
Dear freeipa users/admins,
I'm trying to implement freeipa in our company, so that our Unix admins can
authenticate on Linux servers using their Windows AD account.
Following this guide
https://www.freeipa.org/page/Active_Directory_trust_setup it seems to work
well, they can login without problems.
What I cannot make working is sudo from their AD accounts on Linux.
No matter what I try, it is still:
sudo systemctl restart httpd
[sudo] password for simecek.to...@sd-stc.cz:
Sorry, try again.
Here's our setup:
Freeipa server: CentOS Linux release 7.2.1511 (Core),
ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
Freeipa client: the same
AD domain name: sd-stc.cz
IPA domain: linuxdomain.cz
When digging in logs and googling, I realized that the problem on client
side could be:
[root@spcss-2t-www ~]# kinit -k
kinit: Cannot determine realm for host (principal host/spcss-2t-www@)
But this seems to work:
[root@spcss-2t-www ~]# kinit simecek.to...@sd-stc.cz
Password for simecek.to...@sd-stc.cz:
[root@spcss-2t-www ~]# klist
Default principal: simecek.to...@sd-stc.cz
Valid starting Expires Service principal
07/04/2016 09:36:26 07/04/2016 19:36:26 krbtgt/sd-stc...@sd-stc.cz
renew until 07/05/2016 09:36:23
My /etc/sssd/sssd.conf:
[domain/linuxdomain.cz]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = linuxdomain.cz
krb5_realm = LINUXDOMAIN.CZ
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = spcss-2t-www.linuxdomain.cz
chpass_provider = ipa
ipa_server = svlxxipap.linuxdomain.cz
ldap_tls_cacert = /etc/ipa/ca.crt
override_shell = /bin/bash
sudo_provider = ldap
ldap_uri = ldap://svlxxipap.linuxdomain.cz
ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
ldap_sasl_mech = GSSAPI
ldap_sasl_authid = host/spcss-2t-www.linuxdomain...@linuxdomain.cz
ldap_sasl_realm = LINUXDOMAIN.CZ
krb5_server = svlxxipap.linuxdomain.cz
[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2
domains = linuxdomain.cz
[nss]
homedir_substring = /home
My /etc/krb5.conf:
#File modified by ipa-client-install
includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
default_realm = LINUXDOMAIN.CZ
dns_lookup_realm = true
dns_lookup_kdc = true
rdns = false
ticket_lifetime = 24h
forwardable = yes
udp_preference_limit = 0
default_ccache_name = KEYRING:persistent:%{uid}
[realms]
LINUXDOMAIN.CZ = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
[domain_realm]
.linuxdomain.cz = LINUXDOMAIN.CZ
linuxdomain.cz = LINUXDOMAIN.CZ
Would you please suggest which way to investigate?
Thanks
Tomas Simecek
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Freeipa and sudo
What about /etc/nsswitch.conf?
Does it have "sudo: files sss"?
On Mon, Jul 4, 2016 at 3:50 AM, Tomas Simecek
wrote:
> Dear freeipa users/admins,
> I'm trying to implement freeipa in our company, so that our Unix admins
> can authenticate on Linux servers using their Windows AD account.
> Following this guide
> https://www.freeipa.org/page/Active_Directory_trust_setup it seems to
> work well, they can login without problems.
> What I cannot make working is sudo from their AD accounts on Linux.
>
> No matter what I try, it is still:
>
> sudo systemctl restart httpd
> [sudo] password for simecek.to...@sd-stc.cz:
> Sorry, try again.
>
> Here's our setup:
> Freeipa server: CentOS Linux release 7.2.1511 (Core),
> ipa-server-4.2.0-15.0.1.el7.centos.6.1.x86_64
> Freeipa client: the same
>
> AD domain name: sd-stc.cz
> IPA domain: linuxdomain.cz
>
> When digging in logs and googling, I realized that the problem on client
> side could be:
>
> [root@spcss-2t-www ~]# kinit -k
> kinit: Cannot determine realm for host (principal host/spcss-2t-www@)
>
> But this seems to work:
> [root@spcss-2t-www ~]# kinit simecek.to...@sd-stc.cz
> Password for simecek.to...@sd-stc.cz:
> [root@spcss-2t-www ~]# klist
> Default principal: simecek.to...@sd-stc.cz
>
> Valid starting Expires Service principal
> 07/04/2016 09:36:26 07/04/2016 19:36:26 krbtgt/sd-stc...@sd-stc.cz
> renew until 07/05/2016 09:36:23
>
> My /etc/sssd/sssd.conf:
> [domain/linuxdomain.cz]
>
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = linuxdomain.cz
> krb5_realm = LINUXDOMAIN.CZ
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = spcss-2t-www.linuxdomain.cz
> chpass_provider = ipa
> ipa_server = svlxxipap.linuxdomain.cz
> ldap_tls_cacert = /etc/ipa/ca.crt
> override_shell = /bin/bash
> sudo_provider = ldap
> ldap_uri = ldap://svlxxipap.linuxdomain.cz
> ldap_sudo_search_base = ou=sudoers,dc=linuxdomain,dc=cz
> ldap_sasl_mech = GSSAPI
> ldap_sasl_authid = host/spcss-2t-www.linuxdomain...@linuxdomain.cz
> ldap_sasl_realm = LINUXDOMAIN.CZ
> krb5_server = svlxxipap.linuxdomain.cz
>
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
>
> domains = linuxdomain.cz
> [nss]
> homedir_substring = /home
>
>
> My /etc/krb5.conf:
> #File modified by ipa-client-install
>
> includedir /var/lib/sss/pubconf/krb5.include.d/
>
> [libdefaults]
> default_realm = LINUXDOMAIN.CZ
> dns_lookup_realm = true
> dns_lookup_kdc = true
> rdns = false
> ticket_lifetime = 24h
> forwardable = yes
> udp_preference_limit = 0
> default_ccache_name = KEYRING:persistent:%{uid}
>
>
> [realms]
> LINUXDOMAIN.CZ = {
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> }
>
>
> [domain_realm]
> .linuxdomain.cz = LINUXDOMAIN.CZ
> linuxdomain.cz = LINUXDOMAIN.CZ
>
> Would you please suggest which way to investigate?
>
> Thanks
>
> Tomas Simecek
>
> --
> 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] FreeIPA (directory service) Crash several times a day
On 07/05/2016 12:08 PM, Omar AKHAM wrote:
OK thanks. Ticket URL : https://fedorahosted.org/freeipa/ticket/6030
thanks, I tried to reproduce and failed so far, could you add some
information to the ticket on
- how the entry was created
- a full entry which was seen to crash the server, you don't need to
reveal any real data, jsur which objectclasses and attributes the entry has
On 2016-07-05 10:51, Ludwig Krispenz wrote:
well, this does not have more information:
#0 0x7efe7167c4c0 in ipapwd_keyset_free () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#1 0x7efe7167c742 in ipapwd_encrypt_encode_key () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#2 0x7efe7167c9c8 in ipapwd_gen_hashes () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#3 0x7efe7167c0a7 in ipapwd_SetPassword () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
#4 0x7efe7167e458 in ipapwd_pre_bind () from
/usr/lib64/dirsrv/plugins/libipa_pwd_extop.so
No symbol table info available.
and it looks like a bug in the ipapwd plugin, we would have to
reproduce and work on a fix. I don't see any immediate relief unless
you cannot prevent clients from using password containing arbitrar
octets.
Please open a ticket to get this worked on:
https://fedorahosted.org/freeipa/newticket
Ludwig
On 07/05/2016 12:07 AM, Omar AKHAM wrote:
Ok, here is a new core file : http://pastebin.com/2cJQymHd
Best regards
On 2016-07-04 09:39, Ludwig Krispenz wrote:
On 07/03/2016 03:04 PM, Omar AKHAM wrote:
Where can i find core file of ipa-server?
you still need to look for the core file of slapd, but IPA deploys
plugins for slapd and that is why you need the debuginfo for
ipa-server for a better analysis of the slapd core.
On 2016-07-01 13:29, Ludwig Krispenz wrote:
please keep the discussion on the mailing list
On 07/01/2016 01:17 PM, Omar AKHAM wrote:
Which package to install ? ipa-debuginfo?
yes
2 other crashes last night, with a different user bind this time :
rawdn = 0x7f620003a200
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
dn = 0x7f62000238b0
"uid=XXX,cn=users,cn=accounts,dc=XXX,dc=XX"
saslmech = 0x0
cred = {bv_len = 9, bv_val = 0x7f6200034af0
"nw_PA\250\063\065\067"}
be = 0x7f6254941c20
ber_rc =
rc = 0
sdn = 0x7f62000313f0
bind_sdn_in_pb = 1
referral = 0x0
errorbuf = '\000' ...
supported =
pmech =
authtypebuf =
"\000\000\000\000\000\000\000\000\370\030\002\000b\177\000\000\360\030\002\000b\177\000\000\320\030\002\000b\177\000\000\001\000
\000\000\000\000\000\000\250\311\377+b\177\000\000\320\352\377+b\177\000\000\200\376\002\000b\177\000\000\262\202\211Rb\177\000\000\260\311\377+b\177\
000\000\000\000\000\000\000\000\000\000&\272\200Rb\177\000\000\000\000\000\000\000\000\000\000<\224\204Rb\177\000\000\260\311\377+b\177\000\000\000\00
0\000\000\000\000\000\000\210\311\377+b\177\000\000\250\311\377+b\177",
'\000' , "\002\000\000\000
\305\363Tb\177\000\000\377\377\37
7\377\377\377\377\377\320\030\002\000b\177\000\000\000\000\000\000\000\000\000\000~a\003\000b\177",
'\000'
bind_target_entry = 0x0
On 2016-06-30 18:16, Ludwig Krispenz wrote:
On 06/30/2016 05:54 PM, d...@mdfive.dz wrote:
The crash is random, sometimes the user binds without
probleme, sometimes it bind and there is the error message of
ipa plugin without dirsrv crash. But when it crashes, this
user's bind is found in the new generated core file!
ok, so the user might try or use different passwords. it could be
helpful if you can install the debuginfo for the ipa-server
package
and get a new stack. Please post it to teh list, you can X the
credentials in the core, although I think they will not be proper
credentials.
Ludwig
On 2016-06-30 14:50, Ludwig Krispenz wrote:
On 06/30/2016 02:45 PM, Ludwig Krispenz wrote:
On 06/30/2016 02:27 PM, d...@mdfive.dz wrote:
Hi,
Please find strace on a core file :
http://pastebin.com/v9cUzau4
the crash is in an IPA plugin, ipa_pwd_extop,
to get a better stack you would have to install also the
debuginfo for ipa-server.
but tje stack matches the error messages you have seen
[30/Jun/2016:09:35:19 +0100] ipapwd_encrypt_encode_key - [file
encoding.c, line 171]: generating kerberos keys failed [Invalid
argument]
[30/Jun/2016:09:35:19 +0100] ipapwd_gen_hashes - [file
encoding.c,
line 225]: key encryption/encoding failed
they are from the function sin the call stack.
Looks like the user has a password with a \351 char:
cred = {bv_len = 15, bv_val = 0x7fc7880013a0
"d\351sertification"}
does the crash always happen with a bind from this user ?
and then someone familiar with this plugin should look into it
Regards
On 2016-06-30 12:13, Ludwig Krispenz wrote:
can you get a core file ?
http://www.port389.org/docs/389ds/FAQ/f
Re: [Freeipa-users] Freeipa and sudo
On Tue, Jul 05, 2016 at 09:58:29AM -0400, Danila Ladner wrote: > What about /etc/nsswitch.conf? > Does it have "sudo: files sss"? In general this upstream guide: https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO can help you pinpoint where the issue is. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-client-install --ssh-trust-dns and user ssh key query
Hi, I have successfully installed FreeIPA server version 4.2.0 on CentOS 7.2, including replication between servers. I have a few dozen Ubuntu 14.04 servers joined into IPA for authentication with various user groups controlling access, sudo permissions etc and overall I'm very happy. I have however managed to trip myself up by installing the Ubuntu clients with the --ssh-trust-dns option and now my users ssh keys are not trusted and ssh login falls back to password based on the Ubuntu clients. If I uninstall a client, reboot and then reinstall without the --ssh-trust-dns option then the users ssh key I imported into the web interface is used and login is automatic over ssh. I've looked through all the obvious places (/etc/ssh, sss, pam, etc) and can't see anything to control this. Most of my online searches cover other aspects of ssh host keys in DNS. If I've missed anything obvious then please point me in the right direction. I have a reasonable number of servers to make this change on and ideally I'd like to push out the change to a config file and maybe restart a service. Is this behaviour easy to configure or would it be easier to go through the uninstall/reboot/reinstall loop? Luckily these are all testing servers so not a show stopper but I'd prefer to learn what is actually controlling this. Thanks, Neal. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-client-install --ssh-trust-dns and user ssh key query
Neal Harrington | i-Neda Ltd wrote: Hi, I have successfully installed FreeIPA server version 4.2.0 on CentOS 7.2, including replication between servers. I have a few dozen Ubuntu 14.04 servers joined into IPA for authentication with various user groups controlling access, sudo permissions etc and overall I'm very happy. I have however managed to trip myself up by installing the Ubuntu clients with the --ssh-trust-dns option and now my users ssh keys are not trusted and ssh login falls back to password based on the Ubuntu clients. If I uninstall a client, reboot and then reinstall without the --ssh-trust-dns option then the users ssh key I imported into the web interface is used and login is automatic over ssh. I've looked through all the obvious places (/etc/ssh, sss, pam, etc) and can't see anything to control this. Most of my online searches cover other aspects of ssh host keys in DNS. If I've missed anything obvious then please point me in the right direction. I have a reasonable number of servers to make this change on and ideally I'd like to push out the change to a config file and maybe restart a service. Is this behaviour easy to configure or would it be easier to go through the uninstall/reboot/reinstall loop? Luckily these are all testing servers so not a show stopper but I'd prefer to learn what is actually controlling this. As far as I can tell this option sets this in sshd.conf: VerifyHostKeyDNS = yes HostKeyAlgorithms = ssh-rsa,ssh-dss I assume your DNS doesn't contain the SSHFP entries? 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] Error when adding new users via UI:
Finally got around to fixing this: On Tue, May 24, 2016 at 5:15 PM, Martin Kosek wrote: > On 05/24/2016 04:07 PM, Rob Crittenden wrote: >> Traiano Welcome wrote: >>> Hi >>> >>> I have IPA server 4,2 running on centos 7 >>> (ipa-server-4.2.0-15.el7.centos.3.x86_64). >>> >>> This morning, after many months of stable operation, I tried to add a >>> user and got this error via the web interface: >>> >>> --- >>> Operations error: Allocation of a new value for range cn=posix >>> ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config >>> failed! Unable to proceed. >>> --- >>> >>> So basically, can't add any new users. >>> >>> Would anyone know how I can troubleshoot this kind of IPA error, or >>> possibly have come across and resolved it before ? >> >> At install a range of 100k id's is allocated to IPA. With each new master >> this >> range is divided in half. It appears you've exhausted one of the masters. >> >> What you need to do is take an inventory of what ranges (if any) are >> allocated >> to various masters then you should be able to move things around (this is >> assuming of course that you haven't exhausted the entire range). >> >> ipa-replica-manage list will give you a list of the IPA masters. >> >> ipa-replica-manage dnarange-show and ipa-replica-manage >> dnanextrange-show will help discover what is available. >> >> If you have things in nextrange then I'd start there with reallocation. >> Setting >> a next range of 0-0 removes the next range (e.g. make it available for a >> primary range). >> >> Take care when actually re-assigning ranges. >> This kind of mental gymnastics will probably land you in a lot of trouble :-) >> rob >> > > For the record, what currently did not work is when user is being added on a > master that does not have direct replication connect to other master with > available range. > > This is improved from FreeIPA 4.3.1+: yum update to the most recent patch levels in the 4.2 series seems to fix this. > https://fedorahosted.org/freeipa/ticket/4026 > > Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] how to make fIPA stick to only...
Alexander Bokovoy wrote: On Mon, 04 Jul 2016, lejeczek wrote: On 04/07/16 07:59, Petr Spacek wrote: On 1.7.2016 16:29, lejeczek wrote: On 01/07/16 12:41, Petr Vobornik wrote: On 06/30/2016 04:56 PM, lejeczek wrote: ... its own FQHN and its IP ? hi users, I'm fiddling with rewrites but being an amateur cannot figure it out, it's on a multi/home-IP box. Is it possible? many thanks, L. Hi L. Could you describe your environment and use case in more details. It is not clear to me what you are trying to achieve or what doesn't work for you. Thank you gee, I though my scenario would be quite common among users, take a box with more then one net ifs, or even multiple IPs - what would be nice to have is fIPA webui resides/runs only on that FQHN and that IP to which hostname resolves. Eg, here is one single system: box1.my.dom.local 10.10.1.1 (eg, I go to https://10.10.1.1/) ipa.my.dom.local 10.10.1.2 currently I get fIPA's webui everywhere, but I'd like it to be only at ipa.my.dom.local 10.10.1.2 (either if I URL via hostname or IP) I think it would be great to have included (maybe as comments/options) this in Apache's configs of IPA furure releases, if possible. Is it possible to construct such rules? Or there is different, simpler way? I'm still trying to understand your use-case. Why exactly you need to limit the web UI to one 'host name' while keeping it on the same box? I'm sorry I cannot explain this better, I my mind it's really simple, if I installed an instance of IPA on a ipa.my.dom.local and the system is a multi-homed/IP host I'd like webui to run only on that host/IP This should not even be a matter of "image a situation where" but rather assume that IPA's are deployed on such installations and then - why would fIPA have to monopolize all the IP's/IFs there are? Me, I'd like to be able to use httpd under a root of host's other FQHN/IPs with other things. Your IPA masters hold passwords and keys to your company's infrastructure. We recommend to avoid sharing the servers used for running IPA masters with any other applications because any compromise of those applications can and will be used for taking over your infrastructure as you have so nicely given the keys to its heart by co-sharing the same system. It is up to you on how you make up your system defense. We as FreeIPA upstream developers put considerate effort in ensuring our default setup is secure enough to avoid such breaches. If you want to co-locate other applications, you need to understand what you are doing and how that affects your security. Effectively, you are on your own on this path. FTR, I think this is mostly controlled in ipa-rewrite.conf. If the requested host is not the IPA host or the port is not 443 or the request is for / then ALL requests are redirected to the https://IPAHOST/ipa/ui This file should have enough comments to figure out what part is doing what if you wanted to tweak it. I have to agree with Alexander though. Running multiple services on what should be the core of your infrastructure isn't recommended. 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] Small bug in ipa-backup file naming
On Monday, July 04, 2016 09:01:29 Petr Spacek wrote: > On 2.7.2016 22:00, Joshua J. Kugler wrote: > > Was just playing around with the ipa-backup scripts for a client. Ran ipa- > > backup, and the backup was successfully placed in /var/lib/ipa/backup/ipa- > > full-2016-07-02-11-54-58. Went to view ipa-full.tar, and discovered it's > > actually a tar.gz file. This is FreeIPA 4.2.0 on CentOS 7. > > > > Is this known? Or should I open a bug? > > Please open a ticket: > https://fedorahosted.org/freeipa/newticket > > Thank you! Done, thanks! https://fedorahosted.org/freeipa/ticket/6031 j -- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design jos...@azariah.com - Jabber: pedah...@gmail.com PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A -- 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] AD PDC change
Can I just confirm - the IT team are about to migrate our PDC across town. I presume that the trust relationship is with the domain, not the actual machine itself. So our IPA server will just see the new PDC and everything will be smooth? No need to change any config or create a new trust? Cheers L. -- The most dangerous phrase in the language is, "We've always done it this way." - Grace Hopper -- 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
