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
[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] 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 wrote:
> 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 > > 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
>>
>>
>>
>> >>
>> --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] 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] 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
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 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 specifi
