Re: [Freeipa-users] [Freeipa-interest] Announcing FreeIPA 3.3.0
Congrats team, this is a very nice list of new features. On Aug 8, 2013, at 10:03 AM, Martin Kosek mko...@redhat.com wrote: The FreeIPA team is proud to announce FreeIPA v3.3.0! It can be downloaded from http://www.freeipa.org/page/Downloads. Fedora 19 builds are already on their way to updates-testing repo. == Highlights in 3.3.0 == === New features for 3.3 === * Active Directory integration: ** Support of externally defined POSIX attributes for Active Directory trusted domains ** Automatic discovery of Active Directory identity mapping configuration ** Support of trusted domain users for legacy clients ** Identity mapping for AD users can now be delegated * Performance improvements in processing large number of users and groups * Automated integration testing infrastructure * ipa-advise utility is added to generate client setup advice based on an IPA master configuration * FreeIPA-specific SELinux policies has been merged to the main SELinux policy in Fedora 19 * SSSD 1.11 is required === Active Directory integration === Starting with FreeIPA 3.3, it is possible to define identity ranges for a trusted Active Directory domain that rely on POSIX attributes provided by AD DC instead of generating them out of corresponding security identifiers. This functionality requires Services for Unix (SFU) or Identity Management for UNIX enabled on Active Directory side and is provided mostly to aid with migration to SID-based mapping. In order to support externally defined POSIX attributes, identity ranges have been extended to support new range types: * AD trust with SID-based mapping: 'ipa-ad-trust' (default) * SFU support: 'ipa-ad-trust-posix' 'ipa-ad-trust-posix' range type is activated when range discovery finds out SFU is in use by Active Directory domain. To override automatic detection, --range-type=ipa-ad-trust can be specified to 'ipa trust-add' command. FreeIPA 3.3 requires SSSD 1.11 on the IPA master in order to support externally defined POSIX attributes in AD. More details: http://www.freeipa.org/page/V3/Use_posix_attributes_defined_in_AD FreeIPA 3.3 provides a new way to enable legacy clients to support trusted domain users. A compatibility tree, provided by slapi-nis, can now be configured to look up trusted domain users and handle authentication for them. This functionality relies on SSSD 1.11 and release 0.47.7 of slapi-nis. One can enable legacy clients support by running ipa-adtrust-install and answering positively to the corresponding question. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts Finally, SSSD 1.11 is used to query identity information about trusted domains' users from within IPA framework, including SID to name and name to SID resolution. In addition to speed improvements, FreeIPA 3.3 allows to manage mappings for trusted domains' users without requiring elevated privileges of 'trust admins'. === Performance improvements === When acting on large datasets, FreeIPA now reduces number of potential read roundtrips required to update user and group information. When scaled to thousands of users and groups, this shortens the time required by certain operations tenfold. === Automated testing infrastructure === The FreeIPA team has been providing self-testing code for a long time. The FreeIPA 3.3 test suite includes a framework for integration tests that verify functionality such as replication across several machines. Tests can be run manually, or by test automation servers such as Jenkins or Beaker. Development builds now create a freeipa-tests RPM containing the test suite and related tools. However, as the focus is on testing development code, this package will not be released to Fedora yet. More details: http://www.freeipa.org/page/V3/Integration_testing Additionally, it is now possible to run Web UI tests through the test suite. More details: http://www.freeipa.org/page/Web_UI_Integration_Tests === IPA advise tool === FreeIPA 3.3 introduces new framework to generate recipes of configuration based on how IPA master is configured. These recipes can be taken to the target client systems and used there to configure them for a specific task. We expect to expand use of 'ipa-advise' tool to cover at least configuration of legacy systems in subsequent releases. Three advices are provided with FreeIPA 3.3.0 release: * configuring a generic Fedora release with authconfig tool * configuring RHEL-based systems with SSSD 1.5-1.8 * configuring Debian-based systems with SSSD 1.5-1.8 Contributions are always welcome to grow capabilities of 'ipa-advise' tool to other areas. More details: http://www.freeipa.org/page/V3/Serving_legacy_clients_for_trusts#Major_configuration_options_and_enablement === SELinux policy === SELinux policies specific to FreeIPA have been merged back to the main SELinux policy package in Fedora 19.
Re: [Freeipa-users] tough one on DNS
Hello, I wonder if your problems with SSL are really caused by problems with reverse name resolution ... I think that SSL libraries usually don't care about PTR records. Which SSL libraries do you use? Do you use server's IP address in certificate subject field? Regarding the DNS: First of all, I would recommend to replace conditional forwarder on Windows side by normal DNS delegation from Windows to FreeIPA: Create NS+A record on Windows side, do not configure any forwarding from Windows to FreeIPA. Conditional forwarding usually creates more problems than it solves. Regarding the reverse zone: As you said, the correct approach is to have only one authoritative source for reverse zone - i.e. serve reverse zone only from Windows OR FreeIPA. Do I understand correctly that you want to allow Windows non-Windows clients to update own records in the same reverse zone? It could be a tricky ... What are your security requirements? Do you require Kerberos authentication for each update? Do you have a FreeIPA-Windows trust in place? Obviously, the simplest thing is to not require update signing :-) Now seriously: BIND9 could allow you to specify that authenticated clients from REALM1 and REALM2 can do any update to PTR records in particular reverse zone, but it could be tricky to configure. (See match type 'wildcard' mentioned at ftp://ftp.isc.org/isc/bind9/9.9.3-P1/doc/arm/Bv9ARM.ch06.html#dynamic_update_policies.) If you need more granular control over each update then match type 'external' with your own ACL-daemon could be the way to go. I have no idea how DNS updates from trusted realms are processed on Windows side, it is possible that you can configure Windows to trust updates from FreeIPA realm (if there is a trust between Windows and FreeIPA). Please let us know if you need any further assistance. Petr^2 Spacek On 9.8.2013 15:29, Armstrong, Kenneth Lawrence wrote: Hi all. We have IdM set up in a test environment as a subdomain of our Windows domain (so, linux.example.com) with integrated DNS on the IdM server and forwarders going to the AD servers on example.com. We have on the Windows DNS server the IdM server set up as a conditional forwarder for linux.example.com and an A record in its DNS for the IdM server. However, on example.com, we have other subdomains that need to be able to communicate with the linux.example.com domain, such as tier1.example.com, tier2.example.com, etc. What we are trying to figure out is the whole PTR reverse zone bit, mainly due to the fact that the linux.example.com and the example.com reside on the same subnets (and unfortunately, this is a very large network and we can't change that). For instance, say we have a system at test1.tier2.example.com that needs to make an SSL connection to another system on testA.linux.example.com. The SSL handshake will fail since the PTR record will resolve to a different domain than what the client is expecting, again due to the fact that the reverse zone is on the same subnet. The reverse zone on the Windows DNS server would only contain PTR records for all of the domains except linux.example.com, and the IdM server would only contain PTR records for just the linux.example.com systems. So, obviously, we would not want the IdM server to have a reverse zone, and have it rely on the reverse zone on the Windows DNS server. Other than manually entering PTR records for all Linux systems under linux.example.com to the reverse zone file on the Windows DNS server, is there another way that we can properly accomplish this? Would replicating the reverse zone file from the Windows server to the IdM server take care of that? Thanks. -Kenny -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Blocking 389 and 636 for AD trusts
Hello everyone, I understand this is well documented that we need to block AD from establishing communication to the LDAP ports, but I've never heard an explanation on why this is needed. Additionally, In our environment, we have a 100+ AD servers. Do I need to add an iptables rule for each AD server, on each IPA server or only the ones configured for DNS forwarding? Thanks as always ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Can't update ssh keys
I can get the host keys in okay, it's the user keys that are giving me
fits. No combination of fields seems to work. Before we troubleshoot very
far, I will update to a newer release and try again. Every now and again, I
just need the right motivation to upgrade.
*
*
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
On Mon, Aug 12, 2013 at 11:10 AM, Rob Crittenden rcrit...@redhat.comwrote:
Bret Wortman wrote:
Rob,
I'm running 2.2.1. Sorry about that, I got confused by my Cobbler
version on a different server. I guess we're looking at an upgrade!
For 2.x you might try:
# ipa host-mod host.example.com --sshpubkey=`awk '{ print $2 '}
/etc/ssh/ssh_host_rsa_key.pub`
I'm not 100% sure that the pub key format is space-delimited so YMMV, but
I think this is right.
rob
_
_
*Bret Wortman*
http://damascusgrp.com/
http://about.me/wortmanbret
On Fri, Aug 9, 2013 at 1:22 PM, Rob Crittenden rcrit...@redhat.com
mailto:rcrit...@redhat.com wrote:
Bret Wortman wrote:
Any time I try to use the command-line utilities to add a host
(this
includes ipa-client-install):
#ipa host-mod host.damascusgrp.com http://host.damascusgrp.com
http://bl-1.com/click/load/__**U2IPPgRiUmdQNVY7ATI-b0231http://bl-1.com/click/load/__U2IPPgRiUmdQNVY7ATI-b0231
http://bl-1.com/click/load/**U2IPPgRiUmdQNVY7ATI-b0231http://bl-1.com/click/load/U2IPPgRiUmdQNVY7ATI-b0231
--updatedns
--sshpubkey=`cat /etc/ssh/ssh_host_rsa_key.pub`**__
ipa: ERROR: invliad 'sshpubkey': must be binary data
I know I can use the GUI, but as we could be rolling out a large
number
of systems in coming months, that's not a good long-term option.
So does
anyone know a way to make the CLI tools work?
Second question: is there a way to update the SSHFP records
apart from
using the CLI tools as above?
A pub key consists of 3 pieces of data: the key type, the key and a
comment.
What version of IPA? IIRC in v2 only the key material itself was
supported. This cli command should work with a v3 server which
requires all 3 pieces.
I imagine you could use dnsrecord-mod/add to manage the SSHFP record
but that could lead to different values in the DNS and host entry if
not done carefully.
rob
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Freeipa Active Directory Sync problems
Hi, I have the following error when I try to sync Freeipa 3.2.2 with Active Directory. reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Failed to start replication All current users sync with freeipa, but new users cannot. I have differents OU and I need to sync all users in my active directories. I use the following ipa-replica-manage switches to created the sync. ipa-replica-manage connect --winsync --binddn='cn=Administrator,cn=Users,dc=domain,dc=com' --bindpw='' --cacert=/root/ADCA.cer --passsync='' --win-subtree='OU=test,OU=users,DC=domain,DC=com' windows-server-hostname In the dirsrv logs I have the following error. [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server[12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server[12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=me (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server[12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server[12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - agmt=cn=meTo (nigua:389): Replica has no update vector. It has never been initialized.[12/Aug/2013:10:45:18 -0400] - Entry ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Freeipa Active Directory Sync problems
On 08/12/2013 11:37 AM, luis lugo wrote: Hi, I have the following error when I try to sync Freeipa 3.2.2 with Active Directory. reports: Update failed! Status: [-1 Total update abortedLDAP error: Can't contact LDAP server] Failed to start replication All current users sync with freeipa, but new users cannot. I have differents OU and I need to sync all users in my active directories. I use the following ipa-replica-manage switches to created the sync. ipa-replica-manage connect --winsync --binddn='cn=Administrator,cn=Users,dc=domain,dc=com' --bindpw='' --cacert=/root/ADCA.cer --passsync='' --win-subtree='OU=test,OU=users,DC=domain,DC=com' windows-server-hostname In the dirsrv logs I have the following error. [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=me (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - Replication agreement for agmt=cn=meTo (nigua:389) could not be updated. For replication to take place, please enable the suffix and restart the server [12/Aug/2013:10:45:18 -0400] NSMMReplicationPlugin - agmt=cn=meTo (nigua:389): Replica has no update vector. It has never been initialized. [12/Aug/2013:10:45:18 -0400] - Entry This is truncated. Please provide more. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
