Re: [Freeipa-users] ad relation with winsync
Hi everyone,
I'm back with my winsync replication.
The replication process works fine, but whenI specify
OU=Linux,DC=mycompany,DC=com where 2 users have been created, nothing is
replicated.
btw this is a big AD (90k objects). is it a problem? (idrange for example)
If I replicate cn=Users,DC=company,DC=com I have users replicated. but I'm
not sure that all are replicated.
- Mail original -
De: Nicolas Zin nicolas@savoirfairelinux.com
À: Rich Megginson rmegg...@redhat.com
Cc: freeipa-users@redhat.com
Envoyé: Jeudi 12 Février 2015 09:37:26
Objet: Re: [Freeipa-users] ad relation with winsync
Next step: having the replication working. The customer dont want to give to my
sync user Replicating directory changes, Account Operator and Enterprise
Read-Only Domain Controller attributs and just want a oneway replication.
For the one way replication, I followed the documentation
But I don't see any imported users. Do you have an idea? Are some of the
Windows attributs necessary even for a one way (windows to linux)
synchronisation?
Regards,
Nicolas
- Mail original -
De: Rich Megginson rmegg...@redhat.com
À: freeipa-users@redhat.com
Envoyé: Mercredi 11 Février 2015 18:57:43
Objet: Re: [Freeipa-users] ad relation with winsync
On 02/11/2015 04:18 AM, Nicolas Zin wrote:
I reply to myself.
This was certainly a Windows configurarion issue. I went further:
ipa-replica-manage connect --winsync --binddb
cn=Administrator,cn=Users,dc=company,dc=com --bindpwd passwd --passsync
whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate
database for srv7idm2.ipa.company.com
ipa: INFO: AD Suffix is: DC=company,DC=com
The user for Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com
ipa: INFO: Added new sync agreement, waiting for it to become ready. . .
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error:
Connect error: start: 0 end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP
error: Connect error]
So apparently I manage to connect to AD but something went wrong after?
How can I debug it?
You can test it like this:
# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H
ldap://fqdn.of.ad.host -s base -b DC=company,DC=com -D
cn=Administrator,cn=Users,dc=company,dc=com -w password
Regards,
Nicolas Zin
- Mail original -
De: Nicolas Zin nicolas@savoirfairelinux.com
À: freeipa-users@redhat.com
Envoyé: Mercredi 11 Février 2015 12:06:47
Objet: [Freeipa-users] ad relation with winsync
Hi,
I now try to establish a winsync relation with a Windows 2008R2.
I installed IDM 3.3 on RHEL7.
When I try to create the replication:
ipa-replica-manage connect --winsync --binddb
cn=Administrator,cn=Users,dc=company,dc=com --bindpwd passwd --passsync
whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate
database for srv7idm2.ipa.company.com
ipa: INFO: Failed to connect to AD srever dc.company.com
ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not
found','desc': 'Connect error'}
Failed to setup winsync replication
Do you have an idea, what's wrong?
Also is it possible to point to port 636 instead?
Notes:
- On the windows side, ssl has been activated (with pain) and ldp.exe manage
to connect via ssl on the 636 port correctly (so the certificate is in
place). I don't know how to check it is working properly on port 389, i.e.
START_TLS works
- I checked that the 2 box have the same time (ntp)
- I nearly manage to make it working once, but I got another error during
replication
Nicolas Zin
nicolas@savoirfairelinux.com
Ligne directe: 514-276-5468 poste 135
Fax : 514-276-5465
7275 Saint Urbain
Bureau 200
Montréal, QC, H2R 2Y5
--
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] [Solved] Help with debugging HBACs
On Tue, Feb 17, 2015 at 03:47:39PM -0800, Andrew Egelhofer wrote:
Hi Sumit FreeIPA Users-
Your suggestion on updating the version of sssd worked like a charm.
Consider this issue solved.
Thank you for the feedback, glad I could help.
bye,
Sumit
Thanks Everyone,
-Andrew
On Mon, Feb 16, 2015 at 12:32 PM, Andrew Egelhofer
aegelho...@rubiconproject.com wrote:
Thank you for the reply Sumit - I will look into updating the version of
sssd. If that doesn't work, I will also try adding the
'sourceHostCategory' attribute to rules. Though, I would imagine I would
have to do this for *all* rules if I want them to work as intended. I'll
report back my findings tomorrow.
Thanks,
-Andrew
On Mon, Feb 16, 2015 at 12:40 AM, Sumit Bose sb...@redhat.com wrote:
On Sat, Feb 14, 2015 at 12:52:10PM -0800, Andrew Egelhofer wrote:
Hi FreeIPA Users-
I've deployed a FreeIPA instance in my Lab, and enrolled a single host,
and
a single user ('testuser'). The only HBAC rule I currently have is the
stock allow_all. Yet, when I attempt to log into the host via ssh, it
closes the connection.
$ ssh testuser@host
Warning: Permanently added 'host,host-ip' (RSA) to the list of known
hosts.
testuser@host's password:
Connection closed by host-ip
The host I'm attempting to login to can correctly look up the user using
getent:
# getent passwd testuser
testuser:*:16843:16843:Test User:/home/testuser:/bin/bash
Scanning /var/log/secure, I see these entries:
Feb 14 12:01:50 host sshd[6528]: pam_unix(sshd:auth): authentication
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=172.30.3.58
user=testuser
Feb 14 12:01:51 host sshd[6528]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser=
rhost=172.30.3.58 user=testuser
Feb 14 12:01:51 host sshd[6528]: pam_sss(sshd:account): Access denied
for
user testuser: 6 (Permission denied)
That tells me (From reading online) the user / password was correctly
authenticated, but failed authorization due to HBAC rules. I've tested
the
rule using the 'hbactest' utility and it passes
[root@Master ~]# ipa hbactest --user=testuser --host=host
--service=sshd
Access granted: True
Matched rules: allow_all
I'm at a loss here, because If I comment out the line:
account [default=bad success=ok user_unknown=ignore] pam_sss.so
in /etc/pam.d/system-auth, the user is able to login.
So what am I missing here? Is there a way I can debug HBAC rules? I've
already set debug_level = 10 in /etc/sssd/sssd.conf, and I see its able
to
access the HBAC 'allow_all' rule in the log
/var/log/sssd/sssd_domain.dc
.log:
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[sdap_get_generic_done] (7): Total count [0]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_attrs_to_rule]
(7): Processing rule [allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_user_attrs_to_rule] (7): Processing users for rule [allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_service_attrs_to_rule] (7): Processing PAM services for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_thost_attrs_to_rule] (7): Processing target hosts for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]] [hbac_get_category]
(5): Category is set to 'all'.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_shost_attrs_to_rule] (7): Processing source hosts for rule
[allow_all]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_host_attrs_to_rule] (4): No host specified, rule will never apply.
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (7): [12] groups for [admin]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (7): Added group [admins] for user [admin]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf
[cn=replication
administrators,cn=privileges,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=add
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=modify
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
(Fri Feb 13 21:38:15 2015) [sssd[be[domain.dc]]]
[hbac_eval_user_element] (8): Skipping non-group memberOf [cn=remove
replication agreements,cn=permissions,cn=pbac,dc=domain,dc=dc]
Re: [Freeipa-users] No LDAPS for dirsrv
On Wed, Feb 18, 2015 at 9:34 AM, Alexander Bokovoy aboko...@redhat.com wrote: Unfortunately this still didn't resolve the issue. After the system has been online for about 10 minutes, named starts complaining: Also ldapsearch just hangs if you try to perform any queries. Any ideas what could go wrong here? So, can you get us a backtrace again? Here is a summary of what is going on: After a fresh start of IPA master with 'ipactl start' the system goes wrong after 5-10 minutes. What happens first is that KDC stops responding: kinit thomas.raehalme kinit: Cannot contact any KDC for realm 'EXAMPLE.COM' while getting initial credentials LDAP is still operational, however. It can be verified with ldapsearch. Finally, after total of 15 minutes LDAP is also not responding: Feb 18 10:00:12 ipa named[7410]: LDAP query timed out. Try to adjust timeout parameter Now I took some stacktraces which I will e-mail to you and Rob directly. When I then try to stop dirsrv, it responds but seems to wait indefinitely: [18/Feb/2015:10:03:03 +0200] - slapd shutting down - signaling operation threads [18/Feb/2015:10:03:03 +0200] - slapd shutting down - waiting for 30 threads to terminate I took two stacktraces from this situation as well. Best regards, Thomas -- 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] Cross-Realm authentification
On 5.12.2014 22:24, Petr Spacek wrote: On 5.12.2014 21:53, Alexander Bokovoy wrote: On Fri, 05 Dec 2014, Alexander Bokovoy wrote: On Fri, 05 Dec 2014, Petr Spacek wrote: On 5.12.2014 15:21, Andreas Ladanyi wrote: Am 05.12.2014 um 14:04 schrieb Alexander Bokovoy: Ok, i see one difference: i didnt use the -requires_preauth flag. Why did you use them ? Because this is recommended by MIT documentation. The link between realms has to be protected well, including preauth and good passwords for the cross-realm principals. Is it possible or a good idea to add my trust domain, which isnt a AD domain, manualy to IPA 3.3 ? Well, you can hack of course, that's up to you. I haven't checked that myself and cannot give you definitive answer on this path, though. At this time i havent an idea off the steps in detail how to do that. We may reconsider this check and instead of KRB5KRB_AP_ERR_ILL_CR_TKT return KRB5_PLUGIN_NO_HANDLE to allow fallback to krb5.conf-defined capaths but I remember we had some issues with krb5 versions prior to 1.12 where capaths from krb5.conf were blocking work of the DAL driver. I use MIT Kerberos 1.6 from OpenCSW on Solaris and FreeIPA 3.3.5. So this shouldnt be a problem ?! Sorry i made a little typing mistake. The foreign realm ist MIT Kerberos 1.9.2 and not 1.6 1.6 does not support cross-realm communication as support for RFC6806 was added only in 1.7. So I don't think your setup would have any chance to work at all. Hm.. on the other hand, 1.6 documentation talks about it: http://web.mit.edu/kerberos/krb5-1.6/krb5-1.6.3/doc/krb5-admin.html#Cross_002drealm-Authentication So may be their changelogs aren't as complete as they should be. :) With the link above you can also see with disabling preauth on the cross-realm krbtgt records is recommended. But I think most of your issues were because of the 88 port not being available and no other means to traverse firewall were configured. I will look particular for that. There is no firewall between the two KDCs. That is, aside from the fact that IPA will reject cross-realm tickets because of how we programmed DAL driver as I explained above. I dont know in detail what DAL is doing. OK, it sounds like with IPA my setup wont be very easy :-) I guess that Alexander or Simo could point you to the line in the source code you have to change (or send you one-line patch?) but you will have to recompile the driver from source. Do you want to try this way? Attached please find a patch that solves the issue of cross-realm trust for me: [root@ipa-05-m ~]# kinit admin Password for ad...@ipa5.test: [root@ipa-05-m ~]# KRB5_TRACE=/dev/stderr kvno -S host master.f21.test [16101] 1417810641.441614: Convert service host (service with host as instance) on host master.f21.test to principal [16101] 1417810641.449424: Remote host after forward canonicalization: master.f21.test [16101] 1417810641.449501: Remote host after reverse DNS processing: master.f21.test [16101] 1417810641.449549: Get host realm for master.f21.test [16101] 1417810641.449593: Use local host master.f21.test to get host realm [16101] 1417810641.449630: Look up master.f21.test in the domain_realm map [16101] 1417810641.449655: Look up .f21.test in the domain_realm map [16101] 1417810641.449677: Temporary realm is F21.TEST [16101] 1417810641.449697: Got realm F21.TEST for host master.f21.test [16101] 1417810641.449724: Got service principal host/master.f21.t...@f21.test [16101] 1417810641.449750: Getting credentials ad...@ipa5.test - host/master.f21.t...@f21.test using ccache KEYRING:persistent:0:0 [16101] 1417810641.449888: Retrieving ad...@ipa5.test - host/master.f21.t...@f21.test from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16101] 1417810641.449946: Retrieving ad...@ipa5.test - krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16101] 1417810641.450065: Retrieving ad...@ipa5.test - krbtgt/ipa5.t...@ipa5.test from KEYRING:persistent:0:0 with result: 0/Success [16101] 1417810641.450095: Starting with TGT for client realm: ad...@ipa5.test - krbtgt/ipa5.t...@ipa5.test [16101] 1417810641.450144: Retrieving ad...@ipa5.test - krbtgt/f21.t...@ipa5.test from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16101] 1417810641.450171: Requesting TGT krbtgt/f21.t...@ipa5.test using TGT krbtgt/ipa5.t...@ipa5.test [16101] 1417810641.450216: Generated subkey for TGS request: aes256-cts/3A06 [16101] 1417810641.450267: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [16101] 1417810641.450364: Encoding request body and padata into FAST request [16101] 1417810641.450422: Sending request (890 bytes) to IPA5.TEST [16101] 1417810641.450559: Sending initial UDP request to dgram 192.168.5.109:88 [16101]
[Freeipa-users] New Replacing Master server help
Hey all. We are in the process of essentially moving data centers while additionally changing to new OS(rhel from centos) - so we are building replica with master option servers to the new networks. version 3.0.. its up and is working as any of our instances. Question is how or what do I need to bring over on the new install -replica master(s) to ensure we have all the Original master server information, keys, crt's, CA etc. before we can shut it down for ever (+ a snapshot ;) ) we have struggled understanding exactly what to back up since the 3.0 version is lacking backup scripts. a thought, but not timely present would be to upgrade everything in place then migrate, again not timed right for us. Thanks in advance. Cory -- 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] Passsync fails to connect to LDAP
Sorry to be a pest, but I don't suppose you've heard back about this yet, have you? Thanks, Hugh -- 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] ping: Fwd: Passsync fails to connect to LDAP
Hello Hugh, Could you tell us the version of 389-ds-base the PassSync is trying to access? If the directory server is not new enough (389-ds-base-*1.3.2.26 http://www.port389.org/docs/389ds/releases/release-1-3-2-26.html *or 389-ds-base-http://www.port389.org/docs/389ds/releases/release-1-3-3-8.html*1.3.3.8 http://www.port389.org/docs/389ds/releases/release-1-3-3-8.html*), could you please try setting the following environment variable on the Windows machine on which PassSync is running?* http://www.port389.org/docs/389ds/releases/release-1-3-3-8.html* http://www.port389.org/docs/389ds/releases/release-passsync-1-1-6.html PassSync 1.1.6 supports TLS version 1.1 and newer SSL versions supported by NSS. SSLv3 is disabled, by default. To force to enable SSLv3.0, an environment variable LDAPSSL_ALLOW_OLD_SSL_VERSION has to be set with some non NULL value. In Computer | Properties | Advanced system settings | Environment Variables | System variables, add variable: LDAPSSL_ALLOW_OLD_SSL_VERSION, value: 1 Thanks, --noriko Forwarded Message Subject:[Freeipa-users] Passsync fails to connect to LDAP Date: Tue, 17 Feb 2015 13:55:52 -0600 From: Hugh a...@psychopig.com To: freeipa-users@redhat.com All, After my education on what IPA/AD trusts can and can't do, I decided to give the IPA-AD sync option a try. After finally finding what I think is the proper software to install on the AD DC (389-PassSync-1.1.6-x86_64.exe from the Fedora site), I believe I have the settings correct, but the Password Synchronization software refuses to connect. After changing the Log Level option to 1, I get the below in the log file, which doesn't really tell me much of anything. 02/17/15 13:18:20: Backoff time expired. Attempting sync 02/17/15 13:18:20: Password list has 1 entries 02/17/15 13:18:20: Ldap bind error in Connect 81: Can't contact LDAP server 02/17/15 13:18:20: Attempting to sync password for ADSERVER$ 02/17/15 13:18:20: Searching for (ntuserdomainid=ADSERVER$) 02/17/15 13:18:20: Ldap error in QueryUsername 81: Can't contact LDAP server 02/17/15 13:18:20: Deferring password change for ADSERVER$ 02/17/15 13:18:20: Backing off for 256000ms The credentials are definitely correct and IPA is set up to do LDAPS as, on the same AD server, I can connect and bind using ldp.exe with the same settings/credentials and I'm able to browse the LDAP tree. I've done a wireshark capture and it looks like it's failing in the TLS negotiation. I can see this entry in the capture: TLSv1 Record Layer: Alert (Level: Fatal, Description: Protocol Version) Content Type: Alert (21) Version: TLS 1.2 (0x0303) Length: 2 Alert Message Level: Fatal (2) Description: Protocol Version (70) I added the IPA CA cert to the cert files in the 389 passsynch directory and I can confirm that as below. C:\Program Files\389 Directory Password Synchronizationcertutil -d . -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA cert CT,, When I list that specific certificate, I can see the below in the output. Certificate Trust Flags: SSL Flags: Valid CA Trusted CA Trusted Client CA Email Flags: Object Signing Flags: Any pointers/ideas? Thanks in advance, Hugh -- 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] New Replacing Master server help
On 02/18/2015 12:17 PM, Cory Carlton wrote: Hey all. We are in the process of essentially moving data centers while additionally changing to new OS(rhel from centos) - so we are building replica with master option servers to the new networks. version 3.0.. its up and is working as any of our instances. Question is how or what do I need to bring over on the new install -replica master(s) to ensure we have all the Original master server information, keys, crt's, CA etc. before we can shut it down for ever (+ a snapshot ;) ) we have struggled understanding exactly what to back up since the 3.0 version is lacking backup scripts. a thought, but not timely present would be to upgrade everything in place then migrate, again not timed right for us. Thanks in advance. Cory You need to make sure that at least one of the new replicas (better two) acts as an IPA CA. You need to move CRL generation to one of the new replicas that are CAs You need to move the certificate tracking from the old master to the new replica with CA. After that you can decommission old master. All these procedures are documented on the wiki and RHEL docs. You can also find some hints in these archives. Martin, do you think we need a combined wiki page that covers this use case or we already have something like this? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- 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] ad relation with winsync
On 02/18/2015 01:13 AM, Nicolas Zin wrote:
Hi everyone,
I'm back with my winsync replication.
The replication process works fine, but whenI specify
OU=Linux,DC=mycompany,DC=com where 2 users have been created, nothing is
replicated.
btw this is a big AD (90k objects). is it a problem? (idrange for example)
Not sure. You can enable the replication logging level in 389 to see
what the problem is.
http://www.port389.org/docs/389ds/FAQ/faq.html#troubleshooting
If I replicate cn=Users,DC=company,DC=com I have users replicated. but I'm
not sure that all are replicated.
- Mail original -
De: Nicolas Zin nicolas@savoirfairelinux.com
À: Rich Megginson rmegg...@redhat.com
Cc: freeipa-users@redhat.com
Envoyé: Jeudi 12 Février 2015 09:37:26
Objet: Re: [Freeipa-users] ad relation with winsync
Next step: having the replication working. The customer dont want to give to my sync user Replicating directory
changes, Account Operator and Enterprise Read-Only Domain Controller attributs and just
want a oneway replication.
For the one way replication, I followed the documentation
But I don't see any imported users. Do you have an idea? Are some of the
Windows attributs necessary even for a one way (windows to linux)
synchronisation?
Regards,
Nicolas
- Mail original -
De: Rich Megginson rmegg...@redhat.com
À: freeipa-users@redhat.com
Envoyé: Mercredi 11 Février 2015 18:57:43
Objet: Re: [Freeipa-users] ad relation with winsync
On 02/11/2015 04:18 AM, Nicolas Zin wrote:
I reply to myself.
This was certainly a Windows configurarion issue. I went further:
ipa-replica-manage connect --winsync --binddb
cn=Administrator,cn=Users,dc=company,dc=com --bindpwd passwd --passsync
whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com -v
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database
for srv7idm2.ipa.company.com
ipa: INFO: AD Suffix is: DC=company,DC=com
The user for Windows PassSync service is
uid=passsync,cn=sysaccounts,cn=etc,dc=company,dc=com
ipa: INFO: Added new sync agreement, waiting for it to become ready. . .
ipa: INFO: Replication Update in progress: FALSE: status: -11 - LDAP error:
Connect error: start: 0 end: 0
ipa: INFO: Agreement is ready, starting replication . . .
Starting replication, please wait until this has completed.
[srv7idm2.ipa.company.com] reports: Update failed! Status: [-11 - LDAP error:
Connect error]
So apparently I manage to connect to AD but something went wrong after?
How can I debug it?
You can test it like this:
# LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-DOMAIN ldapsearch -xLLLZZ -H
ldap://fqdn.of.ad.host -s base -b DC=company,DC=com -D
cn=Administrator,cn=Users,dc=company,dc=com -w password
Regards,
Nicolas Zin
- Mail original -
De: Nicolas Zin nicolas@savoirfairelinux.com
À: freeipa-users@redhat.com
Envoyé: Mercredi 11 Février 2015 12:06:47
Objet: [Freeipa-users] ad relation with winsync
Hi,
I now try to establish a winsync relation with a Windows 2008R2.
I installed IDM 3.3 on RHEL7.
When I try to create the replication:
ipa-replica-manage connect --winsync --binddb
cn=Administrator,cn=Users,dc=company,dc=com --bindpwd passwd --passsync
whatever --cacert /etc/openssl/cacerets/adRootCa.crt dc.company.com
Directory Manager password:
Added CA certificate /etc/openldap/cacerts/adRootCA.crt to certificate database
for srv7idm2.ipa.company.com
ipa: INFO: Failed to connect to AD srever dc.company.com
ipa: INFO: The error was: {'info': 'TLS error -8157:Certificate extension not
found','desc': 'Connect error'}
Failed to setup winsync replication
Do you have an idea, what's wrong?
Also is it possible to point to port 636 instead?
Notes:
- On the windows side, ssl has been activated (with pain) and ldp.exe manage to
connect via ssl on the 636 port correctly (so the certificate is in place). I
don't know how to check it is working properly on port 389, i.e. START_TLS works
- I checked that the 2 box have the same time (ntp)
- I nearly manage to make it working once, but I got another error during
replication
Nicolas Zin
nicolas@savoirfairelinux.com
Ligne directe: 514-276-5468 poste 135
Fax : 514-276-5465
7275 Saint Urbain
Bureau 200
Montréal, QC, H2R 2Y5
--
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 Application Specific Passwords
Hi, There is always a tradeoff between ease of use, complexity/cost and security. Looking at what you have written suggests to me that your entire system lacks a proper security / network architecture model and you are trying to enforce a policy from one point, IPA. regards Steven From: freeipa-users-boun...@redhat.com freeipa-users-boun...@redhat.com on behalf of Martin Minkus martin.min...@sonic.com Sent: Thursday, 19 February 2015 1:06 p.m. To: freeipa-users@redhat.com Subject: [Freeipa-users] FreeIPA and Application Specific Passwords Hello all, Am wondering what support FreeIPA has for Application Specific Passwords? My research seems to indicate 'none'. I've seen quite a few people ask about this, usually the example is wanting a separate password for dovecot etc. Google itself implemented this, allowing multiple passwords for imap accounts in gmail so that a stolen phone or ipad doesn't give the thief complete unfettered access to the entire google account. The single password can be easily changed or locked out and even if it is not, it only has access to email. I work for an organisation and we are looking at standardising on FreeIPA for all our single sign on and auth requirements. Except where we don't want single sign on, and separate passwords are advantageous or even required: - Web logins - VPN logins - Tacacs I'm assuming it's somewhat understandable to want to keep web logins separate - web sites are notoriously insecure, and we wouldn't want an employee's web login getting stolen/phished/etc giving an attacker vpn access, kerberos/ldap access to all our linux servers, and tacacs access to network infrastructure. The solution I've seen suggested to others that have asked about FreeIPA or OpenLDAP and Application Specific Passwords seems to be: Just create a separate user login for each application. Messy, but sure. I also see we could extend the schema and add in extra fields like webPassword and vpnPassword, but we'd have to maintain those fields/enforce complexity and length requirements/password expiry ourselves which is less than ideal. Or the final option might just be to run separate ldap instances for each application, so the username stays the same group membership is application specific in each ldap instance, and it gives us the password separation we desire. Also, most users don't need tacacs access or vpn access, though most(all) users will need web application access. Anyway. I'm wondering if there are any other potential options that I have missed? Or some better way we should be going about this? Yeah, we should probably trust our employees with their passwords more but apparently that is not the case. Thanks, 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 -- 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 Application Specific Passwords
Hello all, Am wondering what support FreeIPA has for Application Specific Passwords? My research seems to indicate 'none'. I've seen quite a few people ask about this, usually the example is wanting a separate password for dovecot etc. Google itself implemented this, allowing multiple passwords for imap accounts in gmail so that a stolen phone or ipad doesn't give the thief complete unfettered access to the entire google account. The single password can be easily changed or locked out and even if it is not, it only has access to email. I work for an organisation and we are looking at standardising on FreeIPA for all our single sign on and auth requirements. Except where we don't want single sign on, and separate passwords are advantageous or even required: - Web logins - VPN logins - Tacacs I'm assuming it's somewhat understandable to want to keep web logins separate - web sites are notoriously insecure, and we wouldn't want an employee's web login getting stolen/phished/etc giving an attacker vpn access, kerberos/ldap access to all our linux servers, and tacacs access to network infrastructure. The solution I've seen suggested to others that have asked about FreeIPA or OpenLDAP and Application Specific Passwords seems to be: Just create a separate user login for each application. Messy, but sure. I also see we could extend the schema and add in extra fields like webPassword and vpnPassword, but we'd have to maintain those fields/enforce complexity and length requirements/password expiry ourselves which is less than ideal. Or the final option might just be to run separate ldap instances for each application, so the username stays the same group membership is application specific in each ldap instance, and it gives us the password separation we desire. Also, most users don't need tacacs access or vpn access, though most(all) users will need web application access. Anyway. I'm wondering if there are any other potential options that I have missed? Or some better way we should be going about this? Yeah, we should probably trust our employees with their passwords more but apparently that is not the case. Thanks, 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
