Re: [Freeipa-users] SSSD dyndns_update on machine with multiple IP address

[Martin Basti]

On 03/27/2017 09:40 PM, Jakub Hrozek wrote:

On Mon, Mar 27, 2017 at 06:34:24PM +0200, David Goudet wrote:

Hi,

Thanks to dyndns_update=True parameter, SSSD service on client machine updating 
host DNS entry in FreeIPA.
Everything is fine on machines which have only one IP adress on network 
interface.
I have problem with machines which have more that one IP address on network 
interface: if machine have two IP address, SSSD update host DNS entry with 
these two IP address.

To reproduce the problem:
Host have -IP1- and i add -IP2-
ip addr add -IP2-/26 dev em1

ip addr list:
em1:  mtu 1496 qdisc mq state UP qlen 1000
 link/ether 
 inet -IP1-/26 brd  scope global em1
 inet -IP2-/26 scope global secondary em1
valid_lft forever preferred_lft forever

DNS resolution (dig) before restarting sssd returns only -IP1-. After restarting 
sssd returns -IP1- & -IP2-

In dyndns_update manpage, we have "The IP address of the IPA LDAP connection is used 
for the updates", what does it means? Is it IP address of the DNS server (used to 
update the DNS entry)? or is it IP address on client machine used during LDAP TCP bind 
(-IP1- in my case)?

dyndns_update (boolean)
Optional. This option tells SSSD to automatically update the DNS 
server built into FreeIPA v2 with the IP address of this client.
The update is secured using GSS-TSIG. The IP address of the IPA 
LDAP connection is used for the updates, if it is not otherwise
specified by using the “dyndns_iface” option.

Is it normal behaviour that SSSD add in host DNS entry every IPs enabled on 
client machine?


IIRC we added this to support multiple interfaces (user can choose which 
one to use) and to update both IPv6 () and IPv4 (A) records.


IPA/SSSD cannot reliably determine which IP address to use, it is all or 
none from interface. With the previous behavior users want to use 
different/more addresses than the one which has been detected from LDAP 
connection and it was not possible previously.



Do you have set  dyndns_iface in sssd.conf?

Martin

Looks like this was a deliberate change:
 https://pagure.io/SSSD/sssd/issue/2558
but to be honest, I forgot why exactly we did this. Martin, do you know?


Is it possible to configure SSSD to update DNS with only IP address "primary" 
in ip addr list or which is used to FreeIPA server communication (-IP1- used on TCP 
binding)?

Only if the IP addresses are of different families (v4/v6), then it's
possible to restrict one of the families.


--
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] First-class support for the docker image

[Martin Basti]

On 03/25/2017 12:55 AM, Terence Kent wrote:

Hello,

We've been using the FreeIPA docker image for a few years now with 
great success. I really can't overstate how much we get by using a 
container deployment for FreeIPA. We can now easily test anything from 
version upgrades to orchestration code  against either test data and 
our production data set. That, and we get all the typical docker 
goodness (we can easily move the container between hosts, change the 
underlying OS independently, etc, etc).


That said, lots of the work in the freeipa docker image's gitrepo are 
things that seem like they belong in the freeipa main codebase. We've 
had to trace through the freeipa-container source from time to time to 
diagnose issues and we see situations where the docker build file 
actually modifies python code using text replaces.


This seems both easily breakable and like a lot more work than just 
modifying the source file to optionally support whatever a 
containerized environment needs. Is there a reason to keep container 
support out of the main freeipa project?


Best,
Terence




Hello,

we have plans to update FreeIPA codebase to avoid hacks in Docker, but 
we had more prioritized tasks to do.  However we are looking forward to 
merging community patches to have synchronized FreeIPA code base and 
containerized FreeIPA


It was separated due rapid FreeIPA container development to make it 
possible to work ASAP without waiting for FreeIPA core.


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

[Freeipa-users] Announcing FreeIPA 4.3.3

[Martin Basti]

Release date: 2017-03-23

The FreeIPA team would like to announce FreeIPA 4.3.3 release!

It can be downloaded from http://www.freeipa.org/page/Downloads.

Please note that this is the last upstream release of FreeIPA 4.3.x branch.

This announcement is also available at 
<http://www.freeipa.org/page/Releases/4.3.3>.



== Highlights in 4.3.3 ==
=== Enhancements ===
=== Known Issues ===
=== Bug fixes ===
FreeIPA 4.3.3 is a stabilization release for the features delivered as a
part of 4.3.0. There are more than 20 bug-fixes which details can be seen in
the list of resolved tickets below.

== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing

list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa
channel on Freenode.

== Resolved tickets ==
* 6774 FreeIPA client <= 4.4 fail to parse 4.5 cookies
* 6561 CVE-2016-7030 freeipa: ipa: DoS attack against kerberized 
services by abusing password policy
* 6560 CVE-2016-9575 freeipa: ipa: Insufficient permission check in 
certprofile-mod

* 6485 Document make_delete_command method in UserTracker
* 6378 Tests: Fix failing sudo test
* 6317 backport #6213 Incorrect test for 
DNSForwardPolicyConflictWithEmptyZone warning in test_xmlrpc/test_dns_plugin
* 6316 backport #6199 Received ACIError instead of DuplicatedError in 
stageuser_tests

* 6311 Fix or remove the  `LDAPUpdate.update_from_dict` method
* 6287 Refer to nodes in TestWrongClientDomain replica promotion tests 
as replicas
* 6284 Tests: avoid skipping tests because of missing files when running 
as outoftree

* 6278 Use OAEP padding with custodia (to avoid CVE-2016-6298)
* 6262 Fix integration sudo tests setup and checks
* 6254 kinit_admin raises an exception if server uninstallation is 
called from test teardown with server not installed

* 6244 build: add python-libsss_nss_idmap and python-sss to BuildRequires
* 6205 The ipa-server-upgrade command failed when named-pkcs11 does not 
happen to run during dnf upgrade

* 6177 ca-less test are broken - invalid usage of ipautil.run
* 6167 Incorrect domainlevel info in tests
* 6166 Subsequent external CA installation fails
* 6147 Failing automember tests due to manager output normalization
* 6134 Command "ipa-replica-prepare" not allowed to create line 
replication topology
* 6120 ipa-adtrust-install: when running with --netbios-name="", the 
NetBIOS name is changed without notification

* 6076 Mulitple domain Active Directory Trust conflict
* 6056 custodia.conf and server.keys file is world-readable.
* 6016 ipa-ca-install on replica tries to connect to master:8443
* 5696 Add conflicts with bind-chroot to spec.
== Detailed changelog since 4.3.2 ==
=== Alexander Bokovoy (5) ===
* ipa-kdb: search for password policies globally
* ipa-kdb: simplify trusted domain parent search
* trust: make sure ID range is created for the child domain even if it 
exists

* trust: automatically resolve DNS trust conflicts for triangle trusts
* ipaserver/dcerpc: reformat to make the code closer to pep8

=== Christian Heimes (3) ===
* Use RSA-OAEP instead of RSA PKCS#1 v1.5
* Secure permissions of Custodia server.keys
* RedHatCAService should wait for local Dogtag instance

=== David Kupka (1) ===
* password policy: Add explicit default password policy for hosts and 
services


=== Fraser Tweedale (2) ===
* certprofile-mod: correctly authorise config update
* cert-revoke: fix permission check bypass (CVE-2016-5404)

=== Ganna Kaihorodova (1) ===
* Fix for integration tests replication layouts

=== Jan Cholasta (2) ===
* Revert "spec: add conflict with bind-chroot to freeipa-server-dns"
* install: fix external CA cert validation

=== Lenka Doudova (7) ===
* Document make_delete_command method in UserTracker
* Tests: Fix integration sudo test
* Tests: Fix integration sudo tests setup and checks
* Tests: Avoid skipping tests due to missing files
* Raise error when running ipa-adtrust-install with empty netbios--name
* Tests: Fix failing automember tests
* Tests: Remove DNS configuration from trust tests

=== Martin Babinsky (1) ===
* add python-libsss_nss_idmap and python-sss to BuildRequires

=== Martin Basti (5) ===
* Become IPA 4.3.3
* Update Contributors.txt
* Raise DuplicatedEnrty error when user exists in delete_container
* Catch DNS exceptions during emptyzones named.conf upgrade
* Start named during configuration upgrade.

=== Oleg Fayans (3) ===
* Changed addressing to the client hosts to be replicas
* Disabled raiseonerr in kinit call during topology level check
* Fixed incorrect domainlevel determination in tests

=== Peter Lacko (1) ===
* Test URIs in certificate.

=== Petr Spacek (3) ===
* Tests: fix test_forward_zones in test_xmlrpc/test_dns_plugin
* DNS server upgrade: do not fail when DNS server did not respond
* Fix ipa-replica-prepare's error message about missing local CA instance

=== Petr Vobornik (1

[Freeipa-users] Announcing FreeIPA 4.4.4

[Martin Basti]

Release date: 2017-03-23

The FreeIPA team would like to announce FreeIPA 4.4.4 release!

It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for
Fedora 24 will be available in the official COPR repository 
<https://copr.fedorainfracloud.org/coprs/g/freeipa/freeipa-4-4/>.


This announcement is also available 
at<http://www.freeipa.org/page/Releases/4.4.4>.



== Highlights in 4.4.4 ==
=== Enhancements ===
=== Known Issues ===
=== Bug fixes ===
FreeIPA 4.4.4 is a stabilization release for the features delivered as a
part of 4.4.0.

== Upgrading ==
Upgrade instructions are available on [[Upgrade]] page.

== Feedback ==
Please provide comments, bugs and other feedback via the freeipa-users 
mailing

list (http://www.redhat.com/mailman/listinfo/freeipa-users) or #freeipa
channel on Freenode.

== Resolved tickets ==
* 6776 krb5 1.15 broke DAL principal free
* 6738 Ipa-kra-install fails with weird output when backspace is used 
during typing Directory Manager password
* 6713 ipa: Insufficient permission check for ca-del, ca-disable and 
ca-enable commands (CVE-2017-2590)

* 6647 batch param compatibility is incorrect
* 6608 IPA server installation should check if IPv6 stack is enabled
* 6600 Legacy client tests doesn't have tree domain role.
* 6588 replication race condition prevents IPA to install
* 6575 ipa-replica-install fails on requesting DS cert when master is 
not configured with IPv6
* 6070 ipa-replica-install fails to install when resolv.conf incomplete 
entries

== Detailed changelog since 4.4.3 ==
=== Alexander Bokovoy (1) ===
* ipa-kdb: support KDB DAL version 6.1

=== David Kupka (1) ===
* ipapython.ipautil.nolog_replace: Do not replace empty value

=== Florence Blanc-Renaud (1) ===
* Do not configure PKI ajp redirection to use "::1"

=== Fraser Tweedale (2) ===
* ca: correctly authorise ca-del, ca-enable and ca-disable
* Set up DS TLS on replica in CA-less topology

=== Ganna Kaihorodova (1) ===
* Tests: Add tree root domain role in legacy client tests

=== Jan Cholasta (1) ===
* compat: fix `Any` params in `batch` and `dnsrecord`

=== Martin Basti (7) ===
* Become IPA 4.4.4
* Update Contributors.txt
* FreeIPA 4.4.4 translations
* Bump python-dns to improve processing of non-complete resolv.conf
* Use proper logging for error messages
* Wait until HTTPS principal entry is replicated to replica
* wait_for_entry: use only DN as parameter

=== Stanislav Laznicka (2) ===
* Add debug log in case cookie retrieval went wrong
* Fix cookie with Max-Age processing

=== Tomas Krizek (1) ===
* server install: require IPv6 stack to be enabled

=== Thorsten Scherf (1) ===
* added ssl verification using IPA trust anchor

-- 
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] One kerberos realm, two dns zones and SSHFP records

[Martin Basti]

On 03/22/2017 08:29 PM, Ranbir wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Everyone,

I'm using a fully updated CentOS 7.3 environment for two IPA servers. I
have one kerberos realm, one dns zone with the same name as the
kerberos realm and another dns zone with a different name. DNS is
managed by IPA. For the sake of this message:

realm: REALM.IPA
dnszone1: realm.ipa
dnszone2: random.ipa

When I join a server that's going into the realm.ipa dns zone to the
IPA domain, SSHFP records for that server get automatically created in
realm.ipa. But, when I do the same for a server going into the
random.ipa dns zone, the SSHFP aren't automatically created. I have to
do add the SSHFP records manually after the client install completes.

Why are SSHFP records not added automatically for the second dns zone
and I how can I fix this situation?

Thanks in advance.

Ranbir


- -- 
Ranbir

-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCgAGBQJY0tCCAAoJEN7T/ly5z1dik3cP/0Xx0Vk0cIfbloYJuVb1ffMH
mJzKg3BaSEasWL3mJSsgPQS7CZWFi6PgBZLc79nwJhve1tAZC5+pMwVZwY9F7U9a
liZdK1l7a0agpDwnupISdih5PG6TGNEfVjHezKKwnDgjUWMOqak7BM3KIffjhNzc
SpuZHUDuY8QD2DeyO8iuuJjt+BUiWJ+Weh1OJq4UKWT68wALc/TbdtLi5OWlFtnV
rClTbOhPvm8I4Md3DT0vDdhKqPiUvBGPKgse7HZIN9G4W6/wpM3hU1+ETYgXWqIX
yRSK0rjjxfrWKIqRUB1sCKLlkdd+wMaRa/uCnRgvRhYjYUrwyPaH11N41lvE7zUz
ccJnaZXkDcIWW9wkAQxx3XXx5vHR33VTS13nkZv4QsHSoJOXcqrsr+Q1r28WmLcZ
wb3osINWIEmFCX6knZVRZLDhAefHz+FVsJwzsh6iCdqar+LzFvR0hRUJ0Fepxs8M
bkKEZ3LztTtDssX+AO7CqkMZSQ5DHiT9Yo1gHXr2zTEt3qzxyuE0GjMyXzBWyMV4
TpOXoRVQMUvEEV2ecpEATBEKghqXOMqhSeGAObfdlEKADTt11u8ONxwutFYPxybD
Sxfd6yvg2/QvB8GYgLMkENuJWdwbFYrlb3GQ04TKjcW6TklcRyjsI8x/Wg3LjofQ
AEtlIGyrGau9jPaeHYwd
=mJn4
-END PGP SIGNATURE-



Do you have enabled dynamic-updates in random.ipa. zone?
Could you check nsupdate output in /var/log/ipaclient-install.log ?

--
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] Use SQLite format NSS database?

[Martin Basti]

On 20.03.2017 16:12, Ian Pilcher wrote:
> On 03/20/2017 04:00 AM, David Kupka wrote:
>> Generally I would not recommend touching this on production system.
>> Why do you want to change the database format?
>
> My FreeIPA server also acts as a reverse proxy/TLS endpoint for my
> home sprinkler system (https://opensprinkler.com/), allowing me to
> securely connect to the sprinkler controller from my cell phone when
> I'm out in the yard (out of WiFi range).
>
> Since free 1-year TLS certificates seem to be a thing of the past, I'm
> working on automating the retrieval of 90-day certificates from Let's
> Encrypt.
>
> My current update script has to stop Apache before updating the
> certificate in the NSS database.  It's hardly the end of the world, but
> it would have been nice to be able to load the new certificate into the
> database and just send a SIGHUP to the daemon.
>

Might this help for Lets encrypt ?
https://github.com/freeipa/freeipa-letsencrypt

Martin



signature.asc
Description: OpenPGP digital signature
-- 
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] Errors in IPA logs

[Martin Basti]

On 19.03.2017 22:58, Lachlan Musicman wrote:
> Hi,
>
> I've reported a bug against SSSD and Lukas has pointed to a number of
> FreeIPA errors in our logs.
> I've can't find any information on how I might fix these errors or
> what I might do to mitigate them. Any pointers appreciated:
>
> First error:
>
> [sssd[be[unixdev.domain.org.au ]]]
> [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_mod_group_member] (0x0080): ldb_modify failed: [No such
> attribute](16)[attribute 'member': no matching attribute value while
> deleting attribute on 'name=ipa_bioinf_st...@unixdev.domain.org.au
> ,cn=groups,cn=unixdev.domain.org.au
> ,cn=sysdb']
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_error_to_errno] (0x0020): LDB returned unexpected error: [No
> such attribute]
>
> [sssd[be[unixdev.domain.org.au ]]]
> [sysdb_update_members_ex] (0x0020): Could not remove member
> [simpsonlach...@domain.org.au ]
> from group [name=ipa_bioinf_st...@unixdev.domain.org.au
> ,cn=groups,cn=unixdev.domain.org.au
> ,cn=sysdb]. Skipping
>
>
>
> Second error is long list of errors that look like
>
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected cn in second
> component, got OU
>
> [sssd[be]] [get_ipa_groupname] (0x0020): Expected groups second
> component, got Users
>
>
> I don't know enough about AD to speak meaningfully to these, but a
> quick google shows that a group can have cn=Users as it's second
> component ( see here for example
> https://technet.microsoft.com/en-us/library/dn579255%28v=ws.11%29.aspx )
>
> Is there an LDAP query that I need to define or add to the IPA server?
>
> cheers
> L.
>
>
>
> --
> The most dangerous phrase in the language is, "We've always done it
> this way."
>
> - Grace Hopper
>
>


Hello,

can you describe your deployment more? Your DNs doesn't look like
created by FreeIPA
This is not how FreeIPA's DIT looks
'name=ipa_bioinf_st...@unixdev.domain.org.au
,cn=groups,cn=unixdev.domain.org.au
,cn=sysdb'

Martin


signature.asc
Description: OpenPGP digital signature
-- 
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] replica install seems to hang forever when "--setup-ca" is enabled - any advice?

[Martin Basti]

On 16.03.2017 01:34, Fraser Tweedale wrote:
> On Wed, Mar 15, 2017 at 06:32:42PM -0400, Chris Dagdigian wrote:
>> Any tips for diving into this a bit more to troubleshoot?
>>
>> For the 1st time I'm setting up an ipa-server 4.4 replica with CA features
>> enabled but the replica install seems to hang forever here:
>>
>> ...
>> ...
>> ...
>> Done configuring directory server (dirsrv).
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes 30
>> seconds
>>   [1/27]: creating certificate server user
>>   [2/27]: configuring certificate server instance
>>   [3/27]: stopping certificate server instance to update CS.cfg
>>   [4/27]: backing up CS.cfg
>>   [5/27]: disabling nonces
>>   [6/27]: set up CRL publishing
>>   [7/27]: enable PKIX certificate path discovery and validation
>>   [8/27]: starting certificate server instance
>>
>> < no output after this >
>>
>>
>> The replica-install.log file ends here:
>>
>> ...
>> ...
>> ...
>> 2017-03-15T22:16:05Z DEBUG Starting external process
>> 2017-03-15T22:16:05Z DEBUG args=/bin/systemctl is-active
>> pki-tomcatd@pki-tomcat.service
>> 2017-03-15T22:16:05Z DEBUG Process finished, return code=0
>> 2017-03-15T22:16:05Z DEBUG stdout=active
>>
>> 2017-03-15T22:16:05Z DEBUG stderr=
>> 2017-03-15T22:16:05Z DEBUG wait_for_open_ports: localhost [8080, 8443]
>> timeout 300
>> 2017-03-15T22:16:06Z DEBUG Waiting until the CA is running
>> 2017-03-15T22:16:06Z DEBUG request POST
>> http://deawilidmp001.XXX.org:8080/ca/admin/ca/getStatus
>> 2017-03-15T22:16:06Z DEBUG request body ''
>>
>>
>>
>>
>> I've confirmed that SELINUX is disabled, there is no firewall and the AWS
>> Security Groups are allowing TCP:8080 and TCP:8443 to the replica instance.
>> The systemctl command also verifies that
>> pki-tomcatd@pki-tomcat.service is "active" as well.
>>
>>
>> Any tips for debugging further?
>>
> Could you please provide the /var/log/pki/pki-tomcat/ca/debug log
> file?
>
> Thanks,
> Fraser
>

Could it be this?
https://pagure.io/freeipa/issue/6766



signature.asc
Description: OpenPGP digital signature
-- 
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] Announcing FreeIPA 4.5.0

[Martin Basti]

ers to the files used by Travis CI
* Travis CI: use specific Python version during build
* introduce install step to .travis.yml and cache pip installs
* split out lint to a separate Travis job
* Travis: offload test execution to a separate script
* Travis CI: a separate script to run test tasks
* Put the commands informing and displaying build logs on single line
* travis: mark FreeIPA as python project
* Bump up ipa-docker-test-runner version
* Add a basic test suite for `kadmin.local` interface
* Make `kadmin` family of functions return the result of ipautil.run
* gracefully handle setting replica bind dn group on old masters
* add missing attribute to ipaca replica during CA topology update
* Revert "upgrade: add replica bind DN group check interval to CA
topology config"
* bindinstance: use data in named.conf to determine configuration status
* Use ipa-docker-test-runner to run tests in Travis CI
* Configuration file for ipa-docker-test-runner
* Add 'env_confdir' to constants
* Fix pep-8 transgressions in ipalib/misc.py
* Make `env` and `plugins` commands local again
* Revert "Add 'ipa localenv' subcommand"
* Enhance __repr__ method of Principal
* replication: ensure bind DN group check interval is set on replica config
* upgrade: add replica bind DN group check interval to CA topology config
* Improve the robustness FreeIPA's i18n module and its tests
* Use common procedure to setup initial replication in both domain levels
* ensure that the initial sync using GSSAPI works agains old masters
* replication: refactor the code setting principals as replica bind DNs
* replication: augment setup_promote_replication method
* Turn replication manager group into ReplicationManager class member
* Fix the naming of ipa-dnskeysyncd service principal
* installutils: remove 'install_service_keytab' function
* domain-level agnostic keytab retrieval in httpinstance
* installers: restart DS after KDC is configured
* dsinstance: use keytab retrieval method from parent class
* use DM credentials to retrieve service keytab only in DLO
* Service: common method for service keytab requests
* Turn Kerberos-related properties to Service class members
* Make service user name a class member of Service
* service installers: clean up the inheritance
* fix incorrect invocation of ipa-getkeytab during DL0 host enrollment
* do partial host enrollment in domain level 0 replica install
* Separate function to purge IPA host principals from keytab
* certs: do not re-create NSS database when requesting service cert
* initialize empty /etc/http/alias during server/replica install
* CertDB: add API for non-destructive initialization from PKCS#12 bundle
* test_ipagetkeytab: use system-wide IPA CA cert location in tests
* Extend keytab retrieval test suite to cover new options
* Modernize ipa-getkeytab test suite
* extend ipa-getkeytab to support other LDAP bind methods
* ipa-getkeytab: expose CA cert path as option
* server-del: fix incorrect check for one IPA master
* Revert "Fix install scripts debugging"
* do not use keys() method when iterating through dictionaries
* remove trailing newlines form python modules
* mod_nss: use more robust quoting of NSSNickname directive
* Move character escaping function to ipautil
* Make Continuous installer continuous only during execution phase
* use separate exception handlers for executors and validators
* ipa passwd: use correct normalizer for user principals
* trust-fetch-domains: contact forest DCs when fetching trust domain info
* netgroup: avoid extraneous LDAP search when retrieving primary key from DN
* advise: Use `name` instead of `__name__` to get plugin names
* Use Travis-CI for basic sanity checks
* ldapupdate: Use proper inheritance in BadSyntax exception
* raise ValidationError when deprecated param is passed to command
* Always fetch forest info from root DCs when establishing one-way trust
* factor out `populate_remote_domain` method into module-level function
* Always fetch forest info from root DCs when establishing two-way trust

=== Martin Basti (134) ===
* Become IPA 4.5.0
* Update 4.5 translations
* Add copy-schema-to-ca for RHEL6 to contrib/
* Remove copy-schema-to-ca.py from master branch
* pylint: bump dependency to version >= 1.6
* backup: backup anonymous keytab
* tests: use --setup-kra in tests
* KRA: add --setup-kra to ipa-server-install
* man: add missing --setup-adtrust option to manpage
* ipactl restart: log httplib failues as debug
* Tests: search for disabled users
* Test: DNS nsupdate from dns-update-system-records
* DNS: dns-update-system-record can create nsupdate file
* py3: ipa_generate_password: do not compare None and Int
* py3: change_admin_password: use textual mode
* py3: create DNS zonefile: use textual mode
* py3: upgradeinstance: use bytes literals with LDIF operations
* py3: upgradeinstance: decode data before storing them as backup...
* py3: upgradeinstance: open dse.ldif in textual mode
* custodia: kem.set_keys: 

Re: [Freeipa-users] Mutli site IPA scenario - DNS issue

[Martin Basti]

On 14.03.2017 17:05, Jan Karásek wrote:
> Hi,
> please can you point me to right direction with this issue ?
> Scenario: 
> Site A, Site B, IPA in Site A is already installed with DNS, CA  and i want 
> to create replica to Site B.
> OS: RHEL 7.3, IPA 4.4
>
>
> Site A - 192.168.0.0/24
> IPA_A server interfaces:
> eth0: 192.168.0.10   -- access for clients in Site A
> eth1: 192.168.10.100 -- interface to Site B
> domain: sitea.mylab.test
>
>
> Site B - 192.168.1.0/24
> IPA_B server interfaces:
> eth0: 192.168.1.10   -- access for clients in Site B
> eth1: 192.168.10.200 -- interface to Site A
> domain: siteb.mylab.test
>
>  
> IPA clients can reach only servers in their own site via eth0 - no access to 
> IPA servers in other sites.
> Servers can communicate with each other only via eth1.
> I am having trouble to find out how to set DNS records for this scenario. 
>
> Just now I have IPA_A installed and i want to create replica to IPA_B server.
> DNS for zone sitea.mylab.test:
>
> ipa_aA192.168.0.10
> ...  SRV  ipa_a.sitea.mylab.test
>
> So just now in DNS I have only A record for interface facing Site A. 
>
> Trouble is that server in Site B (ipa_b) is not able to communicate with 
> server in Site A (ipa_a) via 192.168.0.10 address which it gets from DNS, 
> servers can communicate only on eth1 (192.168.10.0/24).
>
>
> So when I point resolv.conf on IPA_B to IPA_A and try to run 
>
> ipa-replica-install --principal admin --admin-password admin_password 
> --setup-dns --setup-ca ...
>
> I can not access IPA_A server because it is resolving to 192.168.0.10.
>
> So is this supported scenario ? What would be solution ? I can probably fix 
> that in /etc/hosts file, but I would like to keep it all in DNS.
>
> Thank you,
>
> Jan
>
Hello,

this is really nonstandard situation for IPA

I suggest to use just one IP address with IPA to makes things less
complicated, can you leave only 192.168.10.{100|200} for ipaservers and
allow the host subnets to communicate with the particular IPA servers?

Why do you want to prevent clients to communicate with the other IPA
server? You will have no backup for clients in case that one replica failed.

If you just want from clients to prefer closer replica you may want to
use IPA location feature
https://www.freeipa.org/page/Howto/IPA_locations and just keep clients
outside of location failing.


If you really need to separate subnets with different IP addresses, you
need DNS views for that and IPA DNS must be configured to respect that.

Martin



signature.asc
Description: OpenPGP digital signature
-- 
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] ldap tree: etc-location & ca-cas

[Martin Basti]

On 11.03.2017 14:11, lejeczek wrote:
> hi everyone
>
> my domain seems ok but I've decided to watch it closely on more
> regular basis and am in a process of learning the tree.
> I found a few +nsuniqueid and I wonder: is there a relation (surely
> is, but how critical) between etc-location & ca-ca?
>
> Both, location and ca have the same
> +nsuniqueid=647ed0ab-b70911e6-b84df1c7-2176fa48.
> My question would be (if I cannot do that with IPA, which I probably
> cannot): do I clean manually both location & ca in one go?
> Or there is a sequence to it?
> And more importantly: what should also check in the tree in relation
> to these two DNs?
>
> many thank,
> L
>
>

Hi,

you have a replication conflict
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


signature.asc
Description: OpenPGP digital signature
-- 
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] What is the next free IP address for a DNS record

[Martin Basti]

On 09.03.2017 13:19, Kees Bakker wrote:
> On 09-03-17 12:08, Martin Basti wrote:
>> Comments inline
>>
>>
>> On 09.03.2017 11:12, Kees Bakker wrote:
>>> Hey,
>>>
>>> Is there an easy way to find out what the next free IP address is when 
>>> adding a new
>>> DNS A record? The web interface sorts the records alphabetically on "Record 
>>> name",
>>> even in-arpa zones. For the latter it would be more convenient to sort 
>>> numerically.
>> No, it depends on your system. FreeIPA is not an authoritative source of
>> IP addresses, this is job for DHCP server or any network management system.
> DHCP, no.
> "any network management system", that would be the DNS service in our FreeIPA.
DNS is not suitable to be a source of unused IP addresses, that's work
for DHCP, DNS has no information about network ranges.
FreeIPA works in different way, you are responsible for creating and
provisioning a host, assigning an IP address and then enroll the host to
FreeIPA (IP address should be automatically updated in DNS). FreeIPA is
so far from being a network management system.

>
>> I don't think that we should sort numerically as DNS names works with
>> bytes, so ASCII sorting is better. Nothing prevents you to use
>> non-numeric domain with PTR RR type.
> In this case I was referring to the reverse DNS records in the in-arpa
> zones. The Record Name for these zones are alway numeric, aren't they?
https://tools.ietf.org/html/rfc2317

>
>>> Anyway, what methods are there to know what IP address to use when adding a 
>>> new
>>> DNS record? Did I overlook something?
>> Usually when you are adding a new A record, you know for which host it
>> belongs, so you should use the IP address of the host.
> I'm not talking about an existing host. I want to add a _new_ host
> with a _new_ DNS A record. There is no IP address yet. And that's exactly
> my problem. What IP address to pick? FreeIPA/DNS is my authority, so to speak.
> But there is no simple method to find the next free IP address.
>
> In the "old days" we had a straightforward bind configuration. I'd had to edit
> two files, one for the domain zone and one for the in-arpa zone. But now the
> DNS server gets its zone information from FreeIPA (through LDAP).
You can use AXFR from DNS to get all records from zone, sort it and
check free IP addresses.
But there is no standard tool for that in DNS. You have to create your
own script
>
>>> BTW. Right now I'm dumping the JSON with
>>>   ipa -vv dnsrecord-find mydomain --sizelimit=9 --all --structured  
>>> 2>&1 >/dev/null
>>> and a Python script to make a list sorted on ip address.
>> Martin
>>




signature.asc
Description: OpenPGP digital signature
-- 
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] Potential problems when using a loadbalancer

[Martin Basti]

On 09.03.2017 11:04, Wimmer Ronald (BCC.B.SO) wrote:
>
> Hi,
>
>  
>
> what kind of challenges will I run into when I want to use a
> loadbalancer in front of my two IPA servers?
>
>  
>
> -  LDAP: Should not be a problem
>
> -  Kerberos: will definitely be a challenge.
> Is this link the solution or am I still missing something:
> http://directory.fedoraproject.org/docs/389ds/howto/howto-loadbalance-gssapi.html
>
> -  Certificates: I stumbled upon a RedHat Knowledgebase entry
> dealing with “Certificate CN not matching when using the
> loadbalancer’s virtual name”: https://access.redhat.com/solutions/547723
>
> -  What else will be a problem that needs to be solved?
>
>  
>
> Any hints regarding the “what else” point would be highly appreciated!
>
>  
>
> Regards,
>
> Ronald
>
>
>
This may help you

https://www.adelton.com/freeipa/freeipa-behind-load-balancer


signature.asc
Description: OpenPGP digital signature
-- 
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] What is the next free IP address for a DNS record

[Martin Basti]

Comments inline


On 09.03.2017 11:12, Kees Bakker wrote:
> Hey,
>
> Is there an easy way to find out what the next free IP address is when adding 
> a new
> DNS A record? The web interface sorts the records alphabetically on "Record 
> name",
> even in-arpa zones. For the latter it would be more convenient to sort 
> numerically.
No, it depends on your system. FreeIPA is not an authoritative source of
IP addresses, this is job for DHCP server or any network management system.

I don't think that we should sort numerically as DNS names works with
bytes, so ASCII sorting is better. Nothing prevents you to use
non-numeric domain with PTR RR type.
>
> Anyway, what methods are there to know what IP address to use when adding a 
> new
> DNS record? Did I overlook something?
Usually when you are adding a new A record, you know for which host it
belongs, so you should use the IP address of the host.

>
> BTW. Right now I'm dumping the JSON with
>   ipa -vv dnsrecord-find mydomain --sizelimit=9 --all --structured  2>&1 
> >/dev/null
> and a Python script to make a list sorted on ip address.

Martin



signature.asc
Description: OpenPGP digital signature
-- 
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] External DNS and replication

[Martin Basti]

On 09.03.2017 09:04, Wimmer Ronald (BCC.B.SO) wrote:
>
> *From:*Martin Basti [mailto:mba...@redhat.com]
> *Sent:* Mittwoch, 08. März 2017 14:54
> *To:* Wimmer Ronald (BCC.B.SO) <ronald.wim...@oebb.at>;
> freeipa-users@redhat.com
> *Subject:* Re: [Freeipa-users] External DNS and replication
>
>  
>
>  
>
>  
>
> On 08.03.2017 14:05, Wimmer Ronald (BCC.B.SO) wrote:
>
> Hi,
>
>  
>
> I am using FreeIPA with external DNS. Is it ok to balance the
> requests between master and replica with DNS SRV records like this:
>
>  
>
> _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88
> ipa1.example.net.
>
> _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88
> ipa1.example.net.
>
> _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net.
>
> _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net.
>
> _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net.
>
> _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net.
>
>  
>
> _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88
> ipa2.example.net.
>
> _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88
> ipa2.example.net.
>
> _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net.
>
> _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net.
>
> _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net.
>
> _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net.
>
>  
>
> _kerberos.example.net. 86400 IN TXT "example.net"
>
> Looks good to me
>
>
> ipa-ca.example.net. 86400 IN A 10.66.39.130
>
>  
>
> What about the “ipa-ca” entry?
>
>
> ipa-ca should contain all A/ records of CA replicas
>
> IPA4.4+ support command `ipa dns-update-system-records --dry-run` to
> get all required records
>
>  
>
> Regards,
>
> Ronald
>
>
>
>
> Martin
>
>  
>
> Thank’s a lot. In https://access.redhat.com/solutions/98043 RedHat
> suggest to use same weight and same priority for the SRV records. Does
> that make sense?
>
Priority should be same, otherwise servers with higher priority will
work only as backups (preferably you should have priority 0).
You can edit weight to distribute more load to beefy servers.

Please note that priority and weight is handled on client side, so it
will work only on clients that are processing SRV with priority and
weight. Some clients may ignore it.

>  
>
> I also noticed that I have no ndp record. Are IPA clients relying on
> that entry? Do I have to create these manually?
>
>  
>
> _ntp._udp.example.net.  86400   IN  SRV 10 50 123
> ipaserver1.example.net.
>
> _ntp._udp.example.net.  86400   IN  SRV 10 50 123
> ipaserver2.example.net.
>
It depends on your system configuration on clients. This is basically
used only by ipa-client-install because AFAIK ntp client doesn't support
SRV lookup.

Usually clients have default NTP client configured so it should work.

>  
>
> Ronald
>
>
>



signature.asc
Description: OpenPGP digital signature
-- 
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] External DNS and replication

[Martin Basti]

On 08.03.2017 14:05, Wimmer Ronald (BCC.B.SO) wrote:
>
> Hi,
>
>  
>
> I am using FreeIPA with external DNS. Is it ok to balance the requests
> between master and replica with DNS SRV records like this:
>
>  
>
> _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa1.example.net.
>
> _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net.
>
> _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa1.example.net.
>
> _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa1.example.net.
>
> _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa1.example.net.
>
>  
>
> _kerberos-master._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kerberos-master._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kerberos._tcp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kerberos._udp.example.net. 86400 IN SRV 10 50 88 ipa2.example.net.
>
> _kpasswd._tcp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net.
>
> _kpasswd._udp.example.net. 86400 IN SRV 10 50 464 ipa2.example.net.
>
> _ldap._tcp.example.net. 86400 IN SRV 10 50 389 ipa2.example.net.
>
> _ntp._udp.example.net. 86400 IN SRV 10 50 123 ipa2.example.net.
>
>  
>
> _kerberos.example.net. 86400 IN TXT "example.net"
>
Looks good to me

> ipa-ca.example.net. 86400 IN A 10.66.39.130
>
>  
>
> What about the “ipa-ca” entry?
>

ipa-ca should contain all A/ records of CA replicas

IPA4.4+ support command `ipa dns-update-system-records --dry-run` to get
all required records
>
>  
>
> Regards,
>
> Ronald
>
>
>

Martin


signature.asc
Description: OpenPGP digital signature
-- 
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] Insufficient privileges to promote the server. (ipa replica 4.4.0 / centos7.3)

[Martin Basti]

On 07.03.2017 18:36, Jake wrote:
> dirserv wasn't running and couldn't get running so I went to rebuild
> the replica and now I get this?
>
> replica is a fresh install, I removed the replica from ipa with
>
> $ ipa-replica-manage del dc1-rd-ipa02.ipa.example.com --force --cleanup
> on the master  c05-rd-ipa01.ipa.example.com
>
> 2017-03-07T17:32:18Z DEBUG Created connection context.ldap2_85375504
> 2017-03-07T17:32:18Z DEBUG raw: domainlevel_get(version=u'2.213')
> 2017-03-07T17:32:18Z DEBUG domainlevel_get(version=u'2.213')
> 2017-03-07T17:32:18Z DEBUG flushing
> ldaps://c05-rd-ipa02.ipa.example.com from SchemaCache
> 2017-03-07T17:32:18Z DEBUG retrieving schema for SchemaCache
> url=ldaps://c05-rd-ipa02.ipa.example.com
> conn=
> 2017-03-07T17:32:18Z DEBUG raw: hostgroup_find(None, cn=u'ipaservers',
> version=u'2.213', host=[u'dc1-rd-ipa02.ipa.example.com'])
> 2017-03-07T17:32:18Z DEBUG hostgroup_find(None, cn=u'ipaservers',
> all=False, raw=False, version=u'2.213', no_members=True,
> pkey_only=False, host=(u'dc1-rd-ipa02.ipa.example.com',))
> 2017-03-07T17:32:18Z DEBUG Destroyed connection context.ldap2_85375504
> 2017-03-07T17:32:18Z 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/ipapython/install/cli.py",
> line 318, in run
> cfgr.run()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 308, in run
> self.validate()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 317, in validate
> for nothing in self._validator():
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 372, in __runner
> self._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 394, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 362, in __runner
> step()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 359, in 
> step = lambda: next(self.__gen)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
> line 81, in run_generator_with_yield_from
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
> line 59, in run_generator_with_yield_from
> value = gen.send(prev_value)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 564, in _configure
> next(validator)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 372, in __runner
> self._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 449, in _handle_exception
> self.__parent._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 394, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 446, in _handle_exception
> super(ComponentBase, self)._handle_exception(exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 394, in _handle_exception
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 362, in __runner
> step()
>   File "/usr/lib/python2.7/site-packages/ipapython/install/core.py",
> line 359, in 
> step = lambda: next(self.__gen)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
> line 81, in run_generator_with_yield_from
> six.reraise(*exc_info)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/util.py",
> line 59, in run_generator_with_yield_from
> value = gen.send(prev_value)
>   File "/usr/lib/python2.7/site-packages/ipapython/install/common.py",
> line 63, in _install
> for nothing in self._installer(self.parent):
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
> line 1712, in main
> promote_check(self)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
> line 364, in decorated
> func(installer)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
> line 386, in decorated
> func(installer)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/server/replicainstall.py",
> line 1311, in promote_check
> sys.exit("\nInsufficient privileges to promote the server.")
>
> 2017-03-07T17:32:18Z DEBUG The ipa-replica-install command failed,
> exception: SystemExit:
> Insufficient privileges to promote the server.
> 2017-03-07T17:32:18Z ERROR
> Insufficient privileges to promote the server.
> 2017-03-07T17:32:18Z ERROR The ipa-replica-install command failed. See
> /var/log/ipareplica-install.log for more information
>
>


Hello,

are you kinited as admin?

Martin


signature.asc
Description: OpenPGP digital signature
-- 

Re: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening

[Martin Basti]

On 02.03.2017 16:55, Chris Herdt wrote:
>
>
> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti <mba...@redhat.com
> <mailto:mba...@redhat.com>> wrote:
>
>
>
> On 02.03.2017 01:07, Chris Herdt wrote:
>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3
>> from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at
>> 
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>> 
>> <https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html>
>>
>> At this step:
>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir
>> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>>
>> I get the error:
>> ERROR cannot connect to 'ldaps://master.example.com
>> <http://master.example.com>'
>>
>> I ran ipa-replica-conncheck and found that port 636 is not
>> accessible:
>> Port check failed! Inaccessible port(s): 636 (TCP)
>>
>> The port is not blocked. I'm wondering where in the configuration
>> for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or
>> if there is a way I can specify to use port 389 for setting up
>> the replica.
>>
>> Thanks!
>>
>> -- 
>> Chris Herdt
>> Systems Administrator
>>
>>
>
> Hello,
> this is known issue only in FreeIPA 4.4.x, this will be fixed  in
> next minor update which should be released soon to RHEL7.3 (I
> don't know how fast it will be in Centos)
>
> so you can wait, or enable it manually (not nice)
>
> sorry for troubles
> Martin
>
>
>
> Thanks for the reply! Before attempting this in my production
> environment, I had set up a similar configuration in a test
> environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica
> on CentOS 7.3) and the ipa-replica-install went fine. I assumed this
> was an issue with my FreeIPA 3.0.0 production server.
>
> To enable the fix manually, I'm assuming I'd need to install FreeIPA
> from source on the intended replica? If I download the 4.4.3 release
> from https://pagure.io/freeipa/releases, will that be sufficient?
Sorry,
I probably misread what you wrote, I thought that port is closed on
replica, but now I see that port is closed on 3.3.0 master, so this is
something different. I'm not aware of any issue on 3.3.0 that should
cause this.

Could you check your configuration on 3.3.0 master? Is port opened on
master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on
master?

Martin



>
> Thanks again.
>
> -- 
> Chris Herdt
> Systems Administrator

-- 
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 4.4 CA Replications

[Martin Basti]

Did you run ipa-ca-install on server2 ?


On 02.03.2017 15:20, Matt Wells wrote:
> Thank you for the response Martin.  Server1 had no flags upon install
> however CA, DNS were selected during the installation.  Server2 was
> joined and then the 'ipa-replica-install --skip-conn-check' used to
> join it.  Manual tests of the ports showed all was good but not in the
> installation so I had to use the '--skip-conn-check'.
> Server1 - 
>   Maximum username length: 32
>   Home directory base: /home
>   Default shell: /bin/sh
>   Default users group: ipausers
>   Default e-mail domain: lci.devdomain.com <http://lci.devdomain.com>
>   Search time limit: 2
>   Search size limit: 100
>   User search fields: uid,givenname,sn,telephonenumber,ou,title
>   Group search fields: cn,description
>   Enable migration mode: FALSE
>   Certificate Subject base: O=LCI.DEVDOMAIN.COM <http://LCI.DEVDOMAIN.COM>
>   Password Expiration Notification (days): 4
>   Password plugin features: AllowNThash
>   SELinux user map order:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>   Default SELinux user: unconfined_u:s0-s0:c0.c1023
>   Default PAC types: nfs:NONE, MS-PAC
>   IPA masters: server1.lci.devdomain.com
> <http://server1.lci.devdomain.com>, server2.lci.devdomain.com
> <http://server2.lci.devdomain.com>
>   IPA CA servers: server1.lci.devdomain.com
> <http://server1.lci.devdomain.com>
>   IPA NTP servers: server1.lci.devdomain.com
> <http://server1.lci.devdomain.com>, server2.lci.devdomain.com
> <http://server2.lci.devdomain.com>
>   IPA CA renewal master: server1.lci.devdomain.com
> <http://server1.lci.devdomain.com>
>
>
>
> On Thu, Mar 2, 2017 at 12:39 AM Martin Basti <mba...@redhat.com
> <mailto:mba...@redhat.com>> wrote:
>
>
>
> On 01.03.2017 22:00, Matt Wells wrote:
>> I have two new IPA 4.4 servers on CentOS7 installed in a lab.  I
>> built the first, joined the second and promoted it to be a
>> master.  Thus far all went well.  
>>
>> I then ran the ipa-ca-install and when I log back in I see that
>> it has "domain,CA" attached to it.  However when I hit the main
>> IPA page it informs me I only have one server in the CA role. 
>>  Drilling down into server2 I see it does not have that role
>> assigned.  
>> I'm certain I missed an easy step but I've been unable to locate
>> it.  
>>
>> Any guidance would be greatly appreciated. 
>>
>>
>
> Hello,
>
> can you provide more info? How did you install servers (options
> used), on which server you ran ipa-ca-install ?
>
>
> Martin
>
> -- 
> *Matt Wells*
> *Lead Systems Architect*
> <https://www.redhat.com/rhtapps/certification/badge/verify/V3WMPVPAQ6I67AJBGN6FZU6N2YAEQU3CUPSQX2KSDXT6RW46LQ3U7PJCSIXUILAFHEDCMJS26CYXW4U5NQYTCNA62RUWOCM34WWBUYQ=>
> <https://www.bridgevine.com/>

-- 
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] cannot connect to ldaps during replica install, port 636 not listening

[Martin Basti]

On 02.03.2017 01:07, Chris Herdt wrote:
I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a 
FreeIPA 3.0.0 master on CentOS 6.8 following the steps at 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html


At this step:
ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir 
/var/lib/ipa/replica-info-replicaname.example.com.gpg


I get the error:
ERROR cannot connect to 'ldaps://master.example.com 
'


I ran ipa-replica-conncheck and found that port 636 is not accessible:
Port check failed! Inaccessible port(s): 636 (TCP)

The port is not blocked. I'm wondering where in the configuration for 
FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there 
is a way I can specify to use port 389 for setting up the replica.


Thanks!

--
Chris Herdt
Systems Administrator




Hello,
this is known issue only in FreeIPA 4.4.x, this will be fixed  in next 
minor update which should be released soon to RHEL7.3 (I don't know how 
fast it will be in Centos)


so you can wait, or enable it manually (not nice)

sorry for troubles
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] IPA 4.4 CA Replications

[Martin Basti]

On 01.03.2017 22:00, Matt Wells wrote:
I have two new IPA 4.4 servers on CentOS7 installed in a lab.  I built 
the first, joined the second and promoted it to be a master.  Thus far 
all went well.


I then ran the ipa-ca-install and when I log back in I see that it has 
"domain,CA" attached to it.  However when I hit the main IPA page it 
informs me I only have one server in the CA role.

 Drilling down into server2 I see it does not have that role assigned.
I'm certain I missed an easy step but I've been unable to locate it.

Any guidance would be greatly appreciated.




Hello,

can you provide more info? How did you install servers (options used), 
on which server you ran ipa-ca-install ?


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] named-pkcs11: option 'serial_autoincrement' is not supported, ignoring

[Martin Basti]

On 26.02.2017 07:35, Jochen Hein wrote:

Jochen Hein  writes:


I'm implementing logcheck on my server and found the following message
in my logs:


Feb 26 05:30:26 freeipa2 named-pkcs11[4935]: option 'serial_autoincrement' is 
not supported, ignoring

| Updates and Upgrades
|
| Replace serial_autoincrement option in /etc/named.conf with serial_remote 
option.
| Dependencies
`

I just tried that and got a message that serial_remote is unknown.
I run a current CentOS 7.3 server.

Jochen


Hello,

the documentation you found is old, it may be applicable to RHEL6.
For current configuration options see section "5.1 Configuration 
options" in https://pagure.io/bind-dyndb-ldap

You can safely remove serial_autoincrement option form your config.

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] named-pkcs11: dns_rdatatype_fromtext() failed for attribute 'idnsTemplateAttribute; cnamerecord': unknown class/type

[Martin Basti]

On 26.02.2017 07:37, Jochen Hein wrote:

When reloading named I get the following message 8 times:

Feb 26 05:30:27 freeipa2 named-pkcs11[4935]: dns_rdatatype_fromtext()
failed for attribute 'idnsTemplateAttribute;cnamerecord': unknown
class/type

I do have cnames in my zones, but what is missing here?
DNS seems to work fine for CNAMEs.

I'm running CentOS 7.3.

Jochen



Hello, you can safely ignore this message, this is template for creating 
location records we just failed to get rid of that message.


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] integrated DNS vs external DNS

[Martin Basti]

Adding freeipa-users back to loop


On 24.02.2017 12:02, Iulian Roman wrote:
On Thu, Feb 23, 2017 at 4:21 PM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:


Hello,

comments inline


On 23.02.2017 15:07, Iulian Roman wrote:

Despite reading the freeipa and Redhat IdM documentation
regarding the DNS , it is still unclear to me if and when is
integrated DNS mandatory .  We do have an environment with a
pretty complex DNS setup , which is in place for years and there
are no  plans to change it.


Integrated DNS is not mandatory at all. Without IPA DNS you have
to manage all IPA system records manually on external DNS



if i understood correctly from the documentation , integrated DNS
is mandatory for configuring AD trust. is that correct ?

No, it is not needed for AD trust, you need to add additional DNS
records



Can the integrated DNS be configured as forward only ? Do the
clients need to have IPA DNS as a resolver or they can just use
existing DNS server ?

You don't need to install IPA DNS.

All records the IPA needs can be received from command `ipa
dns-update-system-records --dry-run` (IPA4.4+)


there are some SRV records (_kerberos, _kpasswd, _ldap, _ntp) reported 
by the above command which would not be easy to add them to existing 
DNS (DNS updates are form based and they allow only A and CNAME 
records). When and by whom are those records used and what is the 
consequence of not adding them  into existing DNS ?




These are mainly used by ipa-clients (SSSD) with dynamic configuration. 
However you may configure client to use static configuration (without 
auto detection of working IPA servers) and it should work. However I'm 
not sure about DNS records required for AD Trust, who is the consumer, 
if only SSSD or not.












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] integrated DNS vs external DNS

[Martin Basti]

Hello,

comments inline


On 23.02.2017 15:07, Iulian Roman wrote:
Despite reading the freeipa and Redhat IdM documentation regarding the 
DNS , it is still unclear to me if and when is integrated DNS 
mandatory .  We do have an environment with a pretty complex DNS setup 
, which is in place for years and there are no  plans to change it.


Integrated DNS is not mandatory at all. Without IPA DNS you have to 
manage all IPA system records manually on external DNS




if i understood correctly from the documentation , integrated DNS is 
mandatory for configuring AD trust. is that correct ?

No, it is not needed for AD trust, you need to add additional DNS records



Can the integrated DNS be configured as forward only ? Do the clients 
need to have IPA DNS as a resolver or they can just use existing DNS 
server ?

You don't need to install IPA DNS.

All records the IPA needs can be received from command `ipa 
dns-update-system-records --dry-run` (IPA4.4+)









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] Dogtag certs did not auto-renew, very stuck!

[Martin Basti]

On 23.02.2017 12:40, Peter Fern wrote:

On 23/02/17 20:27, Martin Basti wrote:

On 23.02.2017 10:21, Timo Aaltonen wrote:

And as you noticed, packaging nss-pem is not a trivial task because of
the way it uses private NSS api's that the libnss maintainer refuses to
make public.. OpenSSL, anyone? :P


We are working on it :) in future IPA may need only openssl

Doesn't this open the GPL/OpenSSL licensing can of worms (for distro !=
Fedora)?

IPA already requires OpenSSL so nothing should change.

--
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] Dogtag certs did not auto-renew, very stuck!

[Martin Basti]

On 23.02.2017 10:21, Timo Aaltonen wrote:

On 23.02.2017 02:04, Peter Fern wrote:

On 23/02/17 05:26, Rob Crittenden wrote:

It's been many moons since I worked on nss-pem but from what I can tell
it should be buildable outside of NSS so can ship as a separate package.
You might try building it locally to see if it resolves the issues for
you. It resides at https://github.com/kdudka/nss-pem

I had to modify an include path, and it links against some static libs
(libfreebl.a, libnssb.a, libnssckfw.a) that are not included in the
current Debian libnss3 packages, so a non-trivial packaging effort.  And
because certmonger appears to use nss directly, linking against a
different libcurl variant is also probably not an option.

There are other issues too - the default cert store path of
/etc/httpd/alias is still used in the deb package, however the correct
path is /etc/apache2/nssdb.

Good stuff, neatly hardcoded in src/dogtag.c. Thanks for pointing this
out, I'll get that fixed at least..

And as you noticed, packaging nss-pem is not a trivial task because of
the way it uses private NSS api's that the libnss maintainer refuses to
make public.. OpenSSL, anyone? :P


We are working on it :) in future IPA may need only openssl


--
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] Recommended approach to VM snapshot prior to upgrade

[Martin Basti]

On 23.02.2017 00:47, Brian Mathis wrote:
I have a 3-node cluster running FreeIPA 4.2 on RHEL 7.2.  I would like 
to upgrade to RHEL 7.3 / IPA 4.4, and I want to make VM snapshots that 
I can rollback to in case there are issues.  What is the recommended 
approach to this?


Should services already be started when running the yum update?

It doesn't matter, updater will stop/start services as needed



Can I shut down each ipa service one by one, snapshot, then upgrade?  
How would replication be affected if I had to rollback to the older 
snapshot after other nodes had been upgraded?
You have to rollback all snapshots for the whole topology and then you 
can start IPA, otherwise replication conflicts may happen.

So I suggest to have snapshots of all servers before upgrade.


Or is it better to shut down all ipa services on all nodes, make 
snapshots, then perform the upgrade?  Obviously that would bring down 
the domain during the upgrade, but it would better ensure integrity.
This is the best for integrity, but in case there is no/low activity on 
servers, then one by one snapshots may work too.




Thanks,

~ Brian Mathis
@orev




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] authenticating with dns

[Martin Basti]

On 22.02.2017 23:26, Aaron Young wrote:

Hello Everyone

I recently lost the master master IPA server setup by the previous 
administrator.
As it stands now, if I try to add a new client, in order to standup a 
new replica, I get errors while trying to setup DNS. This led me to 
look at how authentication worked (I'm new to IPA) and I learned about 
the kerberos tools


I don't know if I'm familiar enough with the terminology to adequately 
describe what I'm experiencing, so I'll give you some of the commands 
and their results


but first, a bit on the design

before I got to this, we had

a <-> b <-> c <-> d

b was the master master

a, happened to point to two test servers nyc02ipa01 and nyc02ipa02 
(not pictured, I discovered them later when c and d started having 
problems)


a - nyc01ipa02
b - nyc01ipa01
c - ld4ipa01
d - ld4ipa02

currently, I have nyc02ipa02 <-> nyc01ipa02
the reason I have it limited like this is because all the other 
servers stopped replicating for one reason or another (mainly that 
they can't authenticate or in one case, there was a database record 
corruption)
Anyway, here are some activities and logs from the latest round of 
fixes and information activities I've been engaging in


22:54:32 root@nyc01ipa02:~# kinit admin
kinit: Clients credentials have been revoked while getting initial 
credentials


Reading through this 
 tells 
me that


# kadmin: modprinc -unlock PRINCNAME

will unlock an account...but if I can't get in

22:54:37 root@nyc01ipa02:~# kadmin
Authenticating as principal root/admin@MF with password.
kadmin: Client 'root/admin@MF' not found in Kerberos database
while initializing kadmin interface

on ld4ipa02, did a

# ipa-client-install --uninstall

then

# ipa-client-install --force-join --enable-dns-updates --permit -f
--ssh-trust-dns --request-cert --automount-location=LD4
--enable-dns-updates

DNS did not update, here is the relevant portion from 
/var/log/ipaclient-install.log


2017-02-20T18:46:49Z DEBUG Writing nsupdate commands to 
/etc/ipa/.dns_update.txt:
2017-02-20T18:46:49Z DEBUG debug

update delete ld4ipa02.mf. IN A
show
send

update delete ld4ipa02.mf. IN 
show
send

update add ld4ipa02.mf. 1200 IN A 10.102.100.140
show
send

2017-02-20T18:46:49Z DEBUG Starting external process
2017-02-20T18:46:49Z DEBUG args=/usr/bin/nsupdate -g 
/etc/ipa/.dns_update.txt
2017-02-20T18:46:49Z DEBUG Process finished, return code=1
2017-02-20T18:46:49Z DEBUG stdout=Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
ld4ipa02.mf. 0 ANY A

2017-02-20T18:46:49Z DEBUG stderr=Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34702
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;ld4ipa02.mf. IN SOA

;; AUTHORITY SECTION:
mf. 1800 IN SOA ld4ipa01.mf. hostmaster.mf. 1487615509 3600 900 1209600 3600

Found zone name: mf
The master is: ld4ipa01.mf
start_gssrequest
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor 
code may provide more information, Minor = Server DNS/ld4ipa01.mf@MF not found 
in Kerberos database.

2017-02-20T18:46:49Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g 
/etc/ipa/.dns_update.txt' returned non-zero exit status 1
2017-02-20T18:46:49Z ERROR Failed to update DNS records.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN A
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query: ld4ipa02.mf IN 
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z DEBUG DNS resolver: Query:140.100.102.10.in-addr.arpa 
. IN PTR
2017-02-20T18:46:49Z DEBUG DNS resolver: No record.
2017-02-20T18:46:49Z WARNING Missing A/ record(s) for host ld4ipa02.mf: 
10.102.100.140.
2017-02-20T18:46:49Z WARNING Missing reverse record(s) for address(es): 
10.102.100.140.

Why isn't there an entry for "DNS/ld4ipa01.mf@MF" in the Kerberos 
database?


klist -ktK /etc/dirsrv/ds.keytab on ld4ipa01 returns

Keytab name: FILE:/etc/dirsrv/ds.keytab

KVNO Timestamp Principal
 ---
--
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0x696a502bc73d209acdd36c42242f7f8aff9dbba1073b34ea018ed3bd9cdfd970)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0xe031464b6948ea34f4291d40fca7a21e)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0xe94a1c98fe79b6317901435d9e9e0257cefe438ff2ec527f)
2 11/17/2016 20:38:39 ldap/ld4ipa01.mf@MF
(0x6aaf4c7fa6b51b9de032b7c6428307b5)
2 11/17/2016 

Re: [Freeipa-users] FreeIPA 4.3.1 ipa-replica-install wrong exit code?

[Martin Basti]

On 23.02.2017 00:17, Diogenes S. Jesus wrote:
We are ansible-playbooking FreeIPA and we don't want to care about if 
freeipa is installed, we just want to ignore errors if it already is - 
but for that the exit code is relevant.
Either the return code is wrong in the code or in the manual - 
according to the manual, it should be 3, but it's currently 1.



ubuntu@ipa02:~$ sudo -i
root@ipa02:~# http_proxy='' https_proxy='' ipa-replica-install 
--dirsrv-cert-file=/etc/ssl/private/ipa02.dev.pfx 
--http-cert-file=/etc/ssl/private/ipa02.dev.pfx --dirsrv-pin=export 
--http-pin=export
ipa.ipapython.install.cli.install_tool(Replica): ERROR  IPA server is 
already configured on this system.
If you want to reinstall the IPA server, please uninstall it first 
using 'ipa-server-install --uninstall'.
ipa.ipapython.install.cli.install_tool(Replica): ERROR  The 
ipa-replica-install command failed. See 
/var/log/ipareplica-install.log for more information


root@ipa02:~# echo $?
1

root@ipa02:~# cat /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG Logging to /var/log/ipareplica-install.log
2017-02-22T22:49:45Z DEBUG ipa-replica-install was invoked with 
arguments [] and options: {'no_dns_sshfp': None, 'skip_schema_check': 
None, 'setup_kra': None, 'ip_addresses': None, 'mkhomedir': None, 
'no_pkinit': None, 'http_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_ntp': None, 'verbose': False, 
'no_forwarders': None, 'keytab': None, 'ssh_trust_dns': None, 
'domain_name': None, 'http_cert_name': None, 'dirsrv_cert_files': 
['/etc/ssl/private/ipa02.dev.pfx'], 'no_dnssec_validation': None, 
'no_reverse': None, 'pkinit_cert_files': None, 'unattended': False, 
'auto_reverse': None, 'auto_forwarders': None, 'no_host_dns': None, 
'no_sshd': None, 'no_ui_redirect': None, 'dirsrv_config_file': None, 
'forwarders': None, 'pkinit_cert_name': None, 'setup_ca': None, 
'realm_name': None, 'skip_conncheck': None, 'no_ssh': None, 
'dirsrv_cert_name': None, 'quiet': False, 'server': None, 'setup_dns': 
None, 'host_name': None, 'log_file': None, 'reverse_zones': None, 
'allow_zone_overlap': None}

2017-02-22T22:49:45Z DEBUG IPA version 4.3.1
2017-02-22T22:49:45Z DEBUG Loading StateFile from 
'/var/lib/ipa/sysrestore/sysrestore.state'
2017-02-22T22:49:45Z DEBUG Loading Index file from 
'/var/lib/ipa/sysrestore/sysrestore.index'

2017-02-22T22:49:45Z DEBUG httpd is configured
2017-02-22T22:49:45Z DEBUG kadmin is configured
2017-02-22T22:49:45Z DEBUG dirsrv is configured
2017-02-22T22:49:45Z DEBUG pki-tomcatd is not configured
2017-02-22T22:49:45Z DEBUG install is not configured
2017-02-22T22:49:45Z DEBUG krb5kdc is configured
2017-02-22T22:49:45Z DEBUG ntpd is configured
2017-02-22T22:49:45Z DEBUG named is not configured
2017-02-22T22:49:45Z DEBUG ipa_memcached is configured
2017-02-22T22:49:45Z DEBUG filestore has files
2017-02-22T22:49:45Z DEBUG   File 
"/usr/lib/python2.7/dist-packages/ipapython/admintool.py", line 171, 
in execute

return_value = self.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/cli.py", 
line 318, in run

cfgr.run()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 308, in run

self.validate()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 317, in validate

for nothing in self._validator():
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 362, in __runner

step()
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 359, in 

step = lambda: next(self.__gen)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 81, in run_generator_with_yield_from

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/util.py", 
line 59, in run_generator_with_yield_from

value = gen.send(prev_value)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 564, in _configure

next(validator)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 372, in __runner

self._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 449, in _handle_exception

self.__parent._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 446, in _handle_exception

super(ComponentBase, self)._handle_exception(exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 394, in _handle_exception

six.reraise(*exc_info)
  File "/usr/lib/python2.7/dist-packages/ipapython/install/core.py", 
line 

Re: [Freeipa-users] How to check if ldap was updated?

[Martin Basti]

On 22.02.2017 13:13, Sandor Juhasz wrote:

Hi,

i would like to know if there is any endpoint, command, plugin, api or 
other way to check if ldap was modified.
I would like to trigger jobs, if user/group attributes are updated and 
polling ldap continuously is not he best

way i guess.

*Sándor Juhász*
System Administrator
*ChemAxon**Ltd*.
Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
Cell: +36704258964




Hello,
*

*we don't have any command/api to detect if LDAP was changed.
for this you can use syncrepl or persistent ldapsearch attached to 
users/groups subtree.


Martin^2
-- 
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] can't add replica: failed to start the directory server

[Martin Basti]

On 16.02.2017 17:21, Tiemen Ruiten wrote:

Hello,

I'm trying to add a third replica to a FreeIPA 4.4 domain (level 1), 
but I'm getting this error:


[tiemen@copernicum ~]$ sudo ipa-replica-install -P admin -w
"XX" --mkhomedir --setup-dns --forwarder 8.8.8.8
--forwarder 8.8.4.4
Checking DNS forwarders, please wait ...
Run connection check to master
Connection check OK
Configuring NTP daemon (ntpd)
  [1/4]: stopping ntpd
  [2/4]: writing configuration
  [3/4]: configuring ntpd to start on boot
  [4/4]: starting ntpd
Done configuring NTP daemon (ntpd).
Configuring directory server (dirsrv). Estimated time: 1 minute
  [1/44]: creating directory server user
  [2/44]: creating directory server instance
  [3/44]: updating configuration in dse.ldif
  [4/44]: restarting directory server
  [5/44]: adding default schema
  [6/44]: enabling memberof plugin
  [7/44]: enabling winsync plugin
  [8/44]: configuring replication version plugin
  [9/44]: enabling IPA enrollment plugin
  [10/44]: enabling ldapi
  [11/44]: configuring uniqueness plugin
  [12/44]: configuring uuid plugin
  [13/44]: configuring modrdn plugin
  [14/44]: configuring DNS plugin
  [15/44]: enabling entryUSN plugin
  [16/44]: configuring lockout plugin
  [17/44]: configuring topology plugin
  [18/44]: creating indices
  [19/44]: enabling referential integrity plugin
  [20/44]: configuring certmap.conf
  [21/44]: configure autobind for root
  [22/44]: configure new location for managed entries
  [23/44]: configure dirsrv ccache
  [24/44]: enabling SASL mapping fallback
  [25/44]: restarting directory server
  [26/44]: creating DS keytab
  [27/44]: retrieving DS Certificate
  [28/44]: restarting directory server
ipa : CRITICAL Failed to restart the directory server
(Command '/bin/systemctl restart dirsrv@IPA-RDMEDIA-COM.service'
returned non-zero exit status 1). See the installation log for
details.
  [29/44]: setting up initial replication
  [error] error: [Errno 111] Connection refused
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR  [Errno
111] Connection refused
ipa.ipapython.install.cli.install_tool(Replica): ERROR  The
ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information


In /var/log/ipareplica-install.log we find:

2017-02-16T15:53:59Z DEBUG   [27/44]: retrieving DS Certificate
2017-02-16T15:53:59Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2017-02-16T15:53:59Z DEBUG Starting external process
2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -L -n IPA.RDMEDIA.COM
 IPA CA -a
2017-02-16T15:53:59Z DEBUG Process finished, return code=255
2017-02-16T15:53:59Z DEBUG stdout=
*2017-02-16T15:53:59Z DEBUG stderr=certutil: Could not find cert:
IPA.RDMEDIA.COM  IPA CA
: PR_FILE_NOT_FOUND_ERROR: File not found*
2017-02-16T15:53:59Z DEBUG Starting external process
2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -N -f
/etc/dirsrv/slapd-IPA-RDMEDIA-COM//pwdfile.txt
2017-02-16T15:53:59Z DEBUG Process finished, return code=0
2017-02-16T15:53:59Z DEBUG stdout=
2017-02-16T15:53:59Z DEBUG stderr=
2017-02-16T15:53:59Z DEBUG Starting external process
2017-02-16T15:53:59Z DEBUG args=/usr/bin/certutil -d
/etc/dirsrv/slapd-IPA-RDMEDIA-COM/ -A -n IPA.RDMEDIA.COM
 IPA CA -t CT,C,C -a
2017-02-16T15:53:59Z DEBUG Process finished, return code=0
2017-02-16T15:53:59Z DEBUG stdout=
2017-02-16T15:53:59Z DEBUG stderr=
2017-02-16T15:53:59Z DEBUG certmonger request is in state
dbus.String(u'NEWLY_ADDED_READING_KEYINFO', variant_level=1)
2017-02-16T15:54:04Z DEBUG certmonger request is in state
dbus.String(u'CA_UNREACHABLE', variant_level=1)
2017-02-16T15:54:04Z DEBUG flushing
ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket from SchemaCache
2017-02-16T15:54:04Z DEBUG retrieving schema for SchemaCache
url=ldapi://%2fvar%2frun%2fslapd-IPA-RDMEDIA-COM.socket
conn=
2017-02-16T15:54:05Z DEBUG   duration: 5 seconds
2017-02-16T15:54:05Z DEBUG   [28/44]: restarting directory server
2017-02-16T15:54:05Z DEBUG Starting external process
2017-02-16T15:54:05Z DEBUG args=/bin/systemctl --system daemon-reload
2017-02-16T15:54:05Z DEBUG Process finished, return code=0
2017-02-16T15:54:05Z DEBUG stdout=
2017-02-16T15:54:05Z DEBUG stderr=
2017-02-16T15:54:05Z DEBUG Starting external process
2017-02-16T15:54:05Z DEBUG args=/bin/systemctl restart

Re: [Freeipa-users] DM Password Reset in 4.4.0

[Martin Basti]

On 15.02.2017 23:11, Jason B. Nance wrote:

Hello All,

I have managed to lose the Directory Manager password for my FreeIPA 4.4.0 
instance.  I've found the following documentation:

 
http://directory.fedoraproject.org/docs/389ds/howto/howto-resetdirmgrpassword.html

And:

 http://www.freeipa.org/page/Howto/Change_Directory_Manager_Password

I'm confused as to whether I need to follow the procedure in the second link 
because of the following note on the page:

 The following procedure is only applicable to FreeIPA 3.2.1 or older. 
Since FreeIPA 3.2.2 (and ticket #3594), the procedure is automated as a part of 
preparing a replica info file by using ipa-replica-prepare

The wording of that seems to indicate that it is a copy/paste from a different 
doc on how to setup PKI (due to the reference to ipa-replica-prepare).

Could someone shed some light on the proper way to go about resetting the 
Directory Manager password in 4.4.0?

Thanks,

j


Hello,

"Following procedure needs to be performed on all FreeIPA replicas with 
PKI." and see Prerequisites


if you have 3.2.1 and older with CA installed you should use this steps, 
otherwise you need only change DM password as is stated in Dirsrv 
documentation.


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] Bind Journal errors

[Martin Basti]

On 15.02.2017 14:10, Raul Dias wrote:

Hello,

My IPA's named daemon start to show this dyndb journal logs:

   error: malformed transaction: 
dyndb-ldap/ipa/master/17.10.10.in-addr.arpa/raw.jnl last serial 
1484327694 != transaction first serial 1484327693


restarting it did not help.

What should I do?

Thanks
-rsd



Hello, could you provide broader context, are there logged any events 
before this error message?

Do you use dns views?

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] Cannot enter $ character in "group name" of "user groups"

[Martin Basti]

On 15.02.2017 10:57, Dimitris Beletsiotis wrote:

Hello,

Despite the documentation that says that we can use $ in "group names" 
the web gui does not allow it, pls see attached.

Is there some option to enable this?

Thanks,
Dimitris Beletsiotis



Hello,

I checked the code and '$' can be used only as the last character in 
group name, so error message is not quite exact


PATTERN_GROUPUSER_NAME = '^[a-zA-Z0-9_.][a-zA-Z0-9_.-]*[a-zA-Z0-9_.$-]?$'

Martin^2
-- 
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] bind-dyndb-ldap, AXFR and DS records

[Martin Basti]

Hello, 

I'm not sure how your DNS data are structured, but usually (properly) DS record 
is located in parent zone, so AXFR for subdomain.exmale.com should not return 
DS record, but AXFR for example.com should return DS record of 
subdomain.example.com.

Martin

- Original Message -
From: "Ben Roberts" 
To: "Tomas Krizek" 
Cc: freeipa-users@redhat.com
Sent: Thursday, February 9, 2017 10:53:38 AM
Subject: Re: [Freeipa-users] bind-dyndb-ldap, AXFR and DS records

Hi Tomas,

> when I add a DS record to LDAP (without any DNSSEC configuration),
> it is included in my AXFR transfer. I'm using bind-dyndb-ldap-10.1.
>
> I suppose you have DNSSEC configured. Could you be affected by the
> limitations mentioned in [1]?

Yes, dnssec is otherwise fully configured (the only bit I don't yet
have is the DS records for the "example.local" parent domain
registered upstream, but that shouldn't have any impact here. I don't
think the linked limitations apply, I'm not attempting to use the CDS
or CDNSKEY record types, and am manually specifying the DS records for
the child zone.

This is with bind 9.11 and bind-dyndb-ldap 11.0.

Regards,
Ben Roberts

-- 
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] IPA replica setup for version 4.4

[Martin Basti]

On 04.02.2017 10:21, deepak dimri wrote:
I am trying to install ipa replica but getting below error when 
running ipa-replica-install


i am following below link for ipa 4.4:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html 



Run connection check to master
ipa.ipapython.install.cli.install_tool(Replica): ERROR  Connection 
check failed!

Please fix your network settings according to error messages above


What could be reason for this error?

Thanks,
Deepak





Hello,

this can be caused by firewall IMO. Could you provide 
ipareplica-install.log ?


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] Is WinSync A Bad Choice?

[Martin Basti]

On 02.02.2017 00:05, Lachlan Musicman wrote:
On 2 February 2017 at 09:51, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:



On 01.02.2017 23:44, Lachlan Musicman wrote:



(aside: does FreeIPA have plans to move toward PatternFly?
http://www.patternfly.org/ )


Unless I missed something, FreeIPA 4.x already uses patternfly

https://ipa.demo1.freeipa.org/ipa/ui/
<https://ipa.demo1.freeipa.org/ipa/ui/>
admin/Secret123


Ah! The thing I am missing is IPA 4.4! (still on 4.2. Upgrade in the 
planning)


cheers
L.


Actually patternfly is there since 4.0.0

http://www.freeipa.org/page/Releases/4.0.0

"""
Web UI adopted Patternfly open interface project to promote design 
commonality and improved user experience. Web UI is now responsive and 
adapts to different screen sizes like mobile or tablets.

"""

So you should see it on 4.2, if not you have something broken :)
-- 
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] Is WinSync A Bad Choice?

[Martin Basti]

On 01.02.2017 23:44, Lachlan Musicman wrote:
On 2 February 2017 at 09:19, Jason B. Nance > wrote:


>- User/group management in general becomes largely a command-line
operation (such as mapping groups so they can be used in HBAC and
sudo rules)

While this is a nice-to-have, it isn't a deal breaker.


This definitely exists in WebUI? Unless you mean something I don't 
understand.


Define groups:
Identity->User Groups (second tab)

Define user mappings:
IPA Server -> ID Views -> Default Trust View

Is that what you mean?

(aside: does FreeIPA have plans to move toward PatternFly? 
http://www.patternfly.org/ )


Unless I missed something, FreeIPA 4.x already uses patternfly

https://ipa.demo1.freeipa.org/ipa/ui/
admin/Secret123

Martin





cheers
L.






-- 
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] unable to delete a user - which has a double??

[Martin Basti]

Hello,

you have to use ldapdelete command and remove it manually

Martin


On 01.02.2017 19:30, lejeczek wrote:

hi all,
take a look:

$ ipa user-find --uid 3501
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: developer
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 3501
  GID: 3501
  Account disabled: False

$ ipa user-find --uid 1104
--
1 user matched
--
  User login: appmgr
  First name: app
  Last name: devel 1
  Home directory: /home.sysops/appmgr
  Login shell: /bin/bash
  Principal alias: appmgr@PRIVATE
  Email address: appmgr@private
  UID: 1104
  GID: 1104
  Account disabled: False

Number of entries returned 1


I think it had something to do with an initial(long time ago) migration.
How to safely delete such a user? Or one of them?

$ ipa user-del appmgr --no-preserve
ipa: ERROR: The search criteria was not specific enough. Expected 1 
and found 2.


many thanks,
L.



--
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] Replica FQDN / Domain question

[Martin Basti]

On 01.02.2017 14:06, Christophe TREFOIS wrote:

Hi all,

Small question which might be naive.

We have an existing setup with 4 replicas, all with FQDNs like 
replica1.example.com  and REALM 
example.com .


We want to add another replica, replica5, whose FQDN would have a 
different domain, so say replica5.example.org 
.
The DNS would be resolvable as it would be managed by the same DNS 
server (outside of our control).


We don’t think this should have any impact.

Is this a fair assumption? We just want to make sure.

Kind regards,
Christophe


It should work, but keep on mind that replica5 will be still part of 
realm EXAMPLE.COM


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] Identification with openLDAP and authorization with FreeIPA

[Martin Basti]

Is there a possibility to migrate OpenLDAP  to IPA DS and use only one 
source of Identity data?


Martin^2


On 31.01.2017 16:30, Michaël Van de Borne wrote:

h, ok, thank you.

But indeed, I would need HBAC and sudo rules in the future.
So I believe the only exit here is to keep openLDAP and FreeIPA in sync.
Any clue on how to do this efficiently?


Thank you,

Cheers,

m.

Le 31-01-17 à 16:23, Alexander Bokovoy a écrit :

On ti, 31 tammi 2017, Michaël Van de Borne wrote:

Hello list,

Here's my situation:
I'm installing Hadoop for a customer, and the Hadoop cluster is 
secured with Kerberos. I used FreeIPA as a KDC.

The customer uses openLDAP as a directory server.

For now, our solution is to copy the whole openLDAP user base to 
FreeIPA, and then use FreeIPA for the identification and 
authorization (all the keytab stuff).

you mean authentication, not authorization here.

But keeping openLDAP and FreeIPA in sync is a nightmare, and I was 
wondering something:
Would it be possible to configure SSSD to simultaneously target the 
openLDAP server to identify a user, and the FreeIPA server to get 
the tickets?

Here is the thing: yes, you can do that by configuring explicitly
identity and authentication providers in sssd.conf. Set identity
provider to ldap and authentication provider to krb5, add necessary
configuration parameters and that would work. No HBAC, no SUDO rules,
etc, but that's what you want, it seems.

Look at sssd-ldap and sssd-krb5 manual pages.

When you configure identity provider to IPA or AD in sssd.conf, you are
just setting defaults for all other providers to the defaults of IPA or
AD provider. If you use a different identity provider, you'd need to
define proper authentication.


That way, we can avoid having to keep openLDAP and FreeIPA in sync...

_*OR*_

Is there an efficient way to keep openLDAP and FreeIPA in sync?





--
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] Search result has been truncated - Configured size limit exceeded

[Martin Basti]

Thanks,

could you check command ipa user-show  if there is a truncation 
warning?


Is possible you can suffer from this bug 
https://fedorahosted.org/freeipa/ticket/6618


how many users do you have?

Martin

On 27.01.2017 13:02, Christophe TREFOIS wrote:

Hi Martin,

Thank you for your swift reply.

Here is the two parameters from that command:

   Search time limit: 2
   Search size limit: 200

Does this tell you anything?

Kind regards,
Christophe


On 27 Jan 2017, at 12:25, Martin Basti <mba...@redhat.com> wrote:



On 27.01.2017 12:18, Christophe TREFOIS wrote:

Dear all,

Since some time now, when we access a user details via the GUI in FreeIPA 4.4, 
we receive a

"Search result has been truncated: Configured size limit exceeded” popup. It 
seems all fields are properly loaded and updating fields etc works.

Does anybody know where this could come from and how to remove this message?

Thank you,
Christophe


Hello,

what is your configured search size limit (ipa config-show)?

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] Search result has been truncated - Configured size limit exceeded

[Martin Basti]

On 27.01.2017 12:18, Christophe TREFOIS wrote:

Dear all,

Since some time now, when we access a user details via the GUI in FreeIPA 4.4, 
we receive a

"Search result has been truncated: Configured size limit exceeded” popup. It 
seems all fields are properly loaded and updating fields etc works.

Does anybody know where this could come from and how to remove this message?

Thank you,
Christophe



Hello,

what is your configured search size limit (ipa config-show)?

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 clean out(reset) FreeIPA,

[Martin Basti]

On 24.01.2017 11:54, Tony Brian Albers wrote:

Hi guys,

Is there a way to expunge everything except admin account from IPA?

We have a supercomputer test installation here that needs it, and a
reset is preferable over a complete reinstall.

TIA

Tony


You can try ipa-backup and ipa-restore, ipa-backup with only admin and 
call IPA restore only as a cleanup


I'm not sure but ipa-backup --data should be enough, if you don't need 
to restore services just content of LDAP DB


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] Lookups Failing With AD Forwarder (and DNSSEC)

[Martin Basti]

On 18.01.2017 20:52, Jason B. Nance wrote:

I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set to an
Active Directory domain controller.  When a client attempts to lookup any DNS
record other than those to which FreeIPA is authoritative the client reports
NXDOMAIN and the FreeIPA server has the following in its logs:

(first lookup)
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no
valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no
valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53

(subsequent lookups)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: validating
@0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error
(broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN':
10.48.8.18#53

In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served by
AD (as is gen.zone).  10.48.8.18 is an AD domain controller for tkc.gen.zone
(and the forwarder the FreeIPA servers are pointed at).

I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes.  We've
tried both NSEC3 and NSEC.

Anyone have guidance as to what may be going on?

Thanks,

j


you use non-existent TLD domain or TLD domain doesn't have DS record of
your zone, so this is expected behavior for DNSSEC considered as attack.
You have to disable DNSSEC validation on all IPA DNS servers in
/etc/named.conf in first case or fix incorrect/missing DS record in
second case.

The 'zone.' is registered TLD, so if you own it you have probably
missing DS record in path, thus broken trust chain.
If you don't own the TLD, you shouldn't use it at all.

Hi Martin,

Thank you for the reply, and sorry for the delay in response.  My employer owns the 
"gen.zone" domain.  It is used internally only, and served by an Active 
Directory domain controller.

It appears, though, that our registrar does not support DNSSEC for .zone 
domains even though the .zone TLD in general does support DNSSEC.

:-\

j






Ok if you own the zone the it is ok, from logs I see it has actually 
issues with "zone." itself. It may mean that the forwarders you are 
using are not DNSSEC compatible, can you try dig +dnssec @forwarder-ip 
zone. DS if answer contains RRSIG records?


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] where is ipa cache?

[Martin Basti]

https://fedorahosted.org/sssd/wiki/Troubleshooting

Please try to troubleshoot using the page ^ above, it is weird that no 
communication between SSSD and server happened.


Martin


On 14.01.2017 13:39, Matrix wrote:

it should be.

you mean 'sss_cache -E' ? i have also tried to use to invalidate 
everything. sudo did not trigger any packets between client and server.


Matrix


-- Original --
*From: * "Fraser Tweedale";;
*Date: * Sat, Jan 14, 2017 07:29 PM
*To: * "Matrix";
*Cc: * "freeipa-users";
*Subject: * Re: [Freeipa-users] where is ipa cache?

On Sat, Jan 14, 2017 at 07:03:00PM +0800, Matrix wrote:
> Hi, all
>
>
> I have removed everything in /var/lib/sss/db. but sudo works fine.
>
>
> I have also tried to capture sudo search packets with tcpdump. I 
found that there is no packets transferred between ipa client and 
server. I am wondering where is ipa cache? in memory?

>
I think it is in memory.  Run `sss-cache -E' to dump the cache.

>
> Best Regards
>
>
> Matrix

> --
> 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] httpd broken

[Martin Basti]

On 15.01.2017 05:50, Gady Notrica wrote:


Hey guys,

After updating my IPA and http packages, httpd and samba are not 
starting. Something weird happening to the python code.


Any idea?

httpd.service - The Apache HTTP Server

Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; 
vendor preset: disabled)


Drop-In: /etc/systemd/system/httpd.service.d

└─ipa.conf

Active: failed (Result: exit-code) since Sat 2017-01-14 23:44:50 EST; 
33s ago


Docs: man:httpd(8)

man:apachectl(8)

Process: 3445 ExecStartPre=/usr/libexec/ipa/ipa-httpd-kdcproxy 
(code=exited, status=1/FAILURE)


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: File 
"/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1643, in 
__wait_for_connection


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: 
wait_for_open_socket(lurl.hostport, timeout)


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: File 
"/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1286, in 
wait_for_open_socket


Jan 14 23:44:50 master.mydomaine.local ipa-httpd-kdcproxy[3445]: raise e



Hello, could you look into /var/log/httpd/error_log  and provide full 
stacktrace and related debug messages if any?


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] secondary out of sync on DNS again [solved]

[Martin Basti]

Have you tried the ldapsearch from the guide I sent you?


On 11.01.2017 17:03, Outback Dingo wrote:

I am still seeing this, and the same message about LDAP

  ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: LDAP data for
instance 'ipa' are being synchronized, please ignore message 'all
zones loaded'
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: bug in
dn_to_dnsname(): multi-valued RDNs are not supported
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]: failed to
convert DN 
'idnsname=store+nsuniqueid=44fbbd0e-d80a11e6-ad7498e5-1ca0119b,idnsname=optimcloud.com.,cn=dns,dc=optimcloud,dc=com'
to DNS name: not implemented
Jan 11 11:02:06 ipa2.optimcloud.com named-pkcs11[2516]:
ldap_sync_search_entry failed: not implemented
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
150.217.162.in-addr.arpa/IN: loaded serial 1484150526
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
optimvoice.co/IN: loaded serial 1484150526
Jan 11 11:02:07 ipa2.optimcloud.com named-pkcs11[2516]: zone
optimcloud.com/IN: loaded serial 1484150526

On Wed, Jan 11, 2017 at 10:56 AM, Martin Basti <mba...@redhat.com> wrote:

Great :)


On 11.01.2017 16:52, Outback Dingo wrote:

damn... DMARC record removed, now synced

On Wed, Jan 11, 2017 at 10:33 AM, Martin Basti <mba...@redhat.com> wrote:

Please try to create a new test user if it is replicated to other
replicas.


I see repl. conflicts please try to investigate them, it may cause a
missing
zone


https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


could you check what do you have in journalctl -u named-pkcs11 on replica
with missing entries?

Martin


On 11.01.2017 16:27, Outback Dingo wrote:

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366

Re: [Freeipa-users] secondary out of sync on DNS again [solved]

[Martin Basti]

Great :)


On 11.01.2017 16:52, Outback Dingo wrote:

damn... DMARC record removed, now synced

On Wed, Jan 11, 2017 at 10:33 AM, Martin Basti <mba...@redhat.com> wrote:

Please try to create a new test user if it is replicated to other replicas.


I see repl. conflicts please try to investigate them, it may cause a missing
zone

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html


could you check what do you have in journalctl -u named-pkcs11 on replica
with missing entries?

Martin


On 11.01.2017 16:27, Outback Dingo wrote:

Not realliy, not like last time but
[root@ipa2 ~]# cd ipa_check_consistency/
[root@ipa2 ipa_check_consistency]# ./ipa_check_consistency -H
ipa2.optimcloud.com -d OPTIMCLOUD.COM
Directory Manager password:
FreeIPA servers:ipa2STATE
=
Active Users1   OK
Stage Users 0   OK
Preserved Users 0   OK
User Groups 4   OK
Hosts   8   OK
Host Groups 2   OK
HBAC Rules  1   OK
SUDO Rules  0   OK
DNS Zones   26  OK
LDAP Conflicts  YES FAIL
Ghost Replicas  NO  OK
Anonymous BIND  YES OK
Replication Status  ipa 0



[07/Jan/2017:23:59:33.034771024 -0500] slapd shutting down - signaling
operation threads - op stack size 1 max work q size 3 max work q stack
size 3
[07/Jan/2017:23:59:33.080148204 -0500] slapd shutting down - waiting
for 26 threads to terminate
[08/Jan/2017:00:01:43.342292791 -0500] SSL alert: Sending pin request
to SVRCore. You may need to run systemd-tty-ask-password-agent to
provide the password.
[08/Jan/2017:00:01:43.348739255 -0500] SSL alert: Security
Initialization: Enabling default cipher set.
[08/Jan/2017:00:01:43.349917267 -0500] SSL alert: Configured NSS Ciphers
[08/Jan/2017:00:01:43.350819261 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.352925341 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.354043098 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.354944795 -0500] SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.355929413 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.356793063 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.357650823 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.358754848 -0500] SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.359655681 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.360741758 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.361650705 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.362718051 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.363594439 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.365599343 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.366719360 -0500] SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.368835924 -0500] SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.370913228 -0500] SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[08/Jan/2017:00:01:43.372972786 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[08/Jan/2017:00:01:43.375008604 -0500] SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.377060277 -0500] SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[08/Jan/2017:00:01:43.379147161 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[08/Jan/2017:00:01:43.381215466 -0500] SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[08/Jan/2017:00:01:43.410666701 -0500] SSL Initialization - Configured
SSL version range: min: TLS1.0, max: TLS1.2
[08/Jan/2017:00:01:43.412541954 -0500] 389-Directory/1.3.5.10
B2016.341. starting up
[08/Jan/2017:00:01:43.432516181 -0500] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match
[08/Jan/2017:00:01:43.455710217 -0500] WARNING: changelog: entry cache
size 2097152 B is less than db size 4096000 B; We recommend to
increase the entry cache size nsslapd-cachememsize.
[08/Jan/2017:00:01:43.461914913 -0500] Detected Disorderly Shutdown
last time Directory Server was running, recovering database.
[08/Jan/2017:00:01:43.832287548 -0500] schema-compat-plugin -
scheduled schema-compat-plugin tree scan in about 5 seconds after the
server startup!
[08/Jan/2017:00:01:43.857795379 -0500] NSACLPlugin - The ACL target
cn=groups,cn=compat,dc=optimcloud,dc=com does not exist
[08/Jan/2017:00:01:43.859681661 -0500] NSACLPlugin - The ACL target
cn=computers,cn=com

Re: [Freeipa-users] secondary out of sync on DNS again

[Martin Basti]

Plugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist
[11/Jan/2017:10:13:13.791355826 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist
[11/Jan/2017:10:13:13.792403901 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist
[11/Jan/2017:10:13:13.793450557 -0500] NSACLPlugin - The ACL target
cn=vaults,cn=kra,dc=optimcloud,dc=com does not exist
[11/Jan/2017:10:13:13.795887627 -0500] NSACLPlugin - The ACL target
cn=ad,cn=etc,dc=optimcloud,dc=com does not exist
[11/Jan/2017:10:13:13.805429364 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not
exist
[11/Jan/2017:10:13:13.806532806 -0500] NSACLPlugin - The ACL target
cn=casigningcert
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=optimcloud,dc=com does not
exist

=

On Wed, Jan 11, 2017 at 10:24 AM, Martin Basti <mba...@redhat.com> wrote:


On 11.01.2017 15:32, Outback Dingo wrote:

not sure why, but the secondary freeipa server is out of sync by a
long shot now, missing dns domains and A records... tried
ipa-replica-manage force-sync --from ipa.optimcloud.com

doesnt seem to be working

HELP!


Do you see any errors in /var/log/dirsrv/slapd-*/errors on servers?

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] secondary out of sync on DNS again

[Martin Basti]

On 11.01.2017 15:32, Outback Dingo wrote:

not sure why, but the secondary freeipa server is out of sync by a
long shot now, missing dns domains and A records... tried
ipa-replica-manage force-sync --from ipa.optimcloud.com

doesnt seem to be working

HELP!



Do you see any errors in /var/log/dirsrv/slapd-*/errors on servers?

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] FreeIPA + /etc/named.conf

[Martin Basti]

On 06.01.2017 18:14, TomK wrote:

On 1/5/2017 2:17 PM, Martin Basti wrote:



On 05.01.2017 20:03, TomK wrote:

Hey All,

QQ.

Should the DNS forwarders be updated in /etc/named.conf? Until I
manually change /etc/named.conf, can't ping the windows AD cluster:
mds.xyz.  Nor can I get dig to resolve the SRV records (dig SRV
_ldap._tcp.mds.xyz).

sssd-ipa-1.14.0-43.el7_3.4.x86_64
ipa-client-4.4.0-14.el7.centos.x86_64

IPA command below indicates that it's set to 'first' but that's not
what's in /etc/named.conf file when I check.  Again, it works if I
change /etc/named.conf manually.



Forwarder settings has priority:

named.conf < global forwarders (ipa dnsconfig-mod) < local dns server
config (ipa dnsserver-*) < forwardzones (applied per query, not as
global forwarder)

so what is in named.conf is usually always overwritten


How did you edited the named.conf?

Does dig @192.168.0.224 SRV _ldap._tcp.mds.xyz. works?
Do you have any errors in journalctl -u named-pkcs11 ??

Martin


Thanks Martin.

Yes, with the manual update of /etc/named.conf this command works, as 
I posted earlier (It doesn't work without the manual update of 
/etc/named.conf to  forward first; ):


dig @192.168.0.224 SRV _ldap._tcp.mds.xyz.

;; ANSWER SECTION:
_ldap._tcp.mds.xyz. 3600IN  SRV 0 100 389 
winad02.mds.xyz.
_ldap._tcp.mds.xyz. 600 IN  SRV 0 100 389 
winad01.mds.xyz.


Yes I stumbled on the journalctl command but really haven't seen 
anything applicable to my scenario AFAIKT.  Nontheless, logs available 
below:


http://microdevsys.com/freeipa/named-pkcs11-working.log
http://microdevsys.com/freeipa/named-pkcs11-non-working.log
http://microdevsys.com/freeipa/named-pkcs11-working-again.log

I'm still going over them.  The only message that seamed to make sense 
was:


ignoring inherited 'forward first;' for zone '.' - did you want 
'forward only;' to override automatic empty zone


but it appears in both the working and non-working situations so isn't 
looking significant ATM and nothing I found applied to this scenario.  
Btw:


[root@idmipa01 log]# cat /etc/resolv.conf
search nix.mds.xyz mds.xyz
nameserver 127.0.0.1
You have new mail in /var/spool/mail/root
[root@idmipa01 log]#

And based on earlier chats, that's how it should stay.  Resolution of 
AD ID's does work from clients though (When I have forward first; in 
/etc/named.conf)







For me it looks like some DNSSEC validation issue, could you temporarily 
disable DNSSEC validation in /etc/named.conf on IPA server and then try 
again with forward only?


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] Replication has stopped and server errors

[Martin Basti]

On 06.01.2017 00:29, sipazzo wrote:
I have6 ipa servers in 3 locations running 4.2.0-15.0.1on RHEL 7. 
Ipa1-dev is the CA Renewal and CRL Master server and where most of our 
updates (host enrollment, password changes) end up taking place.
Servers had been running fine. Over the holidays we started having 
some replication issues and looking at 
/var/log/dirsrv/slapd-REALM-COM/errors showed the following:


All servers currently have these errors for each replica the 
respective IPA servers are connected to:
NSMMReplicationPlugin - agmt="cn=meToipa2-dr.example.local" 
(ipa2-dr:389): Incremental update failed and requires administrator action
[04/Jan/2017:15:39:48 -0800] agmt="cn=meToipa1-dr.example.local" 
(ipa1-dr:389) - Can't locate CSN 583c8e7400060011 in the changelog 
(DB rc=-30988). If replication stops, the consumer may need to be 
reinitialized
NSMMReplicationPlugin - agmt="cn=meToipa1-prod.example.local" 
(ipa1-prod:389): Data required to update replica has been purged. The 
replica must be reinitialized.
[04/Jan/2017:13:33:26 -0800] NSMMReplicationPlugin - 
agmt="cn=meToipa2-dev.example.local" (ipa2-dev:389): Incremental 
update failed and requires administrator action
[04/Jan/2017:13:33:26 -0800] NSMMReplicationPlugin - 
agmt="cn=meToipa1-prod.example.local" (ipa1-prod:389): Incremental 
update failed and requires administrator action
[04/Jan/2017:13:33:27 -0800] agmt="cn=meToipa2-prod.example.local" 
(ipa2-prod:389) - Can't locate CSN 586d69f40012 in the 
changelog (DB rc=-30988). If replication stops, the consumer may need 
to be reinitialized.
And all servers have these types of errors which are worrisome but 
they go back quite a way

*NSACL*Plugin - The ACL target cn=dns,dc=example,dc=local does not exist
*NSACL*Plugin - The ACL target cn=dns,dc=example,dc=local does not exist
*NSACL*Plugin - The ACL target cn=groups,cn=compat,dc=example,dc=local 
does not exist
*NSACL*Plugin - The ACL target 
cn=computers,cn=compat,dc=example,dc=local does not exist
*NSACL*Plugin - The ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=local does not exist
*NSACL*Plugin - The ACL target cn=casigningcert 
cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=local does not exist
*NSACL*Plugin - The ACL target ou=sudoers,dc=networkfleet,dc=local 
does not exist

^^^ just INFO messages, you can ignore them



All servers except one have a lot of these
DSRetroclPlugin - delete_changerecord: could not delete change record
Ipa1-dev only has this
04/Jan/2017:18:36:52 -0800] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa1-prod.example.local-pki-tomcat" 
(ipa1-prod:389): Replication bind with *SIMPLE* auth resumed
[04/Jan/2017:18:36:52 -0800] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa2-dr.example.local-pki-tomcat" 
(ipa2-dr:389): Replication bind with *SIMPLE* auth resumed
[04/Jan/2017:18:36:52 -0800] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa1-dr.example.local-pki-tomcat" 
(ipa1-dr:389): Replication bind with *SIMPLE* auth resumed
[04/Jan/2017:18:36:53 -0800] NSMMReplicationPlugin - 
agmt="cn=masterAgreement1-ipa2-prod.example.local-pki-tomcat" 
(ipa2-prod:389): Replication bind with *SIMPLE* auth resumed

3 servers (ipa1-dr ipa2-dr ipa2-prod) have these errors:
[01/Jan/2017:14:43:06 -0800] - libdb: BDB2055 Lock table is out of 
available lock entries
[01/Jan/2017:14:43:06 -0800] - compactdb: failed to compact changelog; 
db error - 12 Cannot allocate memory


you probably need https://access.redhat.com/solutions/1241063 to 
increase number of locks (or in this thread 
https://lists.fedoraproject.org/pipermail/389-users/2011-June/013299.html)


I would first increase the number of locks, and then look if something 
improved.
We also don't know how your topology looks like, which servers are 
connected together.


Martin


4 servers (ipa1-dev, ipa2-dev, ipa1-dr and ipa2-dr) have these errors
[04/Jan/2017:15:37:21 -0800] slapd_ldap_sasl_interactive_bind - Error: 
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
-1 (Can't contact LDAP server) ((null)) errno 107 (*Transport* 
endpoint is not connected)
[04/Jan/2017:15:37:24 -0800] slapd_ldap_sasl_interactive_bind - Error: 
could not perform interactive bind for id [] mech [GSSAPI]: LDAP error 
-1 (Can't contact LDAP server) ((null)) errno 107 (*Transport* 
endpoint is not connected)


I have tried various combinations or restarting, re-initializing, 
disconnecting and reconnecting replicas but am down to only two 
servers replicating with each other currently (ipa1-dev and ipa2-dev). 
We did have a power outage at the dev location but it does not seem to 
correspond to when the errors started? Not sure how to recover from 
this. Any help is appreciated





-- 
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 DNS (named)

[Martin Basti]

On 06.01.2017 15:38, Günther J. Niederwimmer wrote:

Hello List,

I have configured my domain (DNSSEC) with Freeipa

Now I have to configure a internal ZONE with the same Domain NAME but with
internal IP's.

Is it possible to add a "view "internal""  "view "external"" to the named.conf
or is this overwritten from the FreeIPA DNS Module ??


No it will not work, IPA managed zones cannot be in views, there is no 
support in bind-dyndb-ldap plugin for that.
This is still valid 
https://www.redhat.com/archives/freeipa-users/2016-July/msg00434.html


Is a other way possible to do this with FreeIPA?


No, you can create views only for zones which aren't managed by IPA



Thanks for a answer,



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] FreeIPA + /etc/named.conf

[Martin Basti]

On 05.01.2017 20:03, TomK wrote:

Hey All,

QQ.

Should the DNS forwarders be updated in /etc/named.conf?  Until I 
manually change /etc/named.conf, can't ping the windows AD cluster: 
mds.xyz.  Nor can I get dig to resolve the SRV records (dig SRV 
_ldap._tcp.mds.xyz).


sssd-ipa-1.14.0-43.el7_3.4.x86_64
ipa-client-4.4.0-14.el7.centos.x86_64

IPA command below indicates that it's set to 'first' but that's not 
what's in /etc/named.conf file when I check.  Again, it works if I 
change /etc/named.conf manually.




Forwarder settings has priority:

named.conf < global forwarders (ipa dnsconfig-mod) < local dns server 
config (ipa dnsserver-*) < forwardzones (applied per query, not as 
global forwarder)


so what is in named.conf is usually always overwritten


How did you edited the named.conf?

Does dig @192.168.0.224 SRV _ldap._tcp.mds.xyz. works?
Do you have any errors in journalctl -u named-pkcs11 ??

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] Fwd: ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

Hello,

could you check this link 
https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/NamedCannotStart#a4.Invalidcredentials:bindtoLDAPserverfailed


kinit prints nothing when it works, so it works in your case, can you 
after kinit as DNS service try to use ldapsearch -Y GSSAPI ?



Martin



On 05.01.2017 14:58, Jeff Goddard wrote:


-- Forwarded message --
From: *Jeff Goddard* <jgodd...@emerlyn.com <mailto:jgodd...@emerlyn.com>>
Date: Thu, Jan 5, 2017 at 8:57 AM
Subject: Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP 
server failed: {'desc': 'Invalid credentials'}

To: Martin Basti <mba...@redhat.com <mailto:mba...@redhat.com>>




On Thu, Jan 5, 2017 at 3:43 AM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:




On 04.01.2017 22:21, Jeff Goddard wrote:

I don't want to hijack someone else's thread but I'm having what
appears to be the same problem and have not seen a solution
presented yet.

Here is the output of journalctl -xe after having tried to start
named:

Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
loading configuration from '/etc/named.conf'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
reading built-in trusted keys from file '/etc/named.iscdlv.key'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
using default UDP/IPv4 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
using default UDP/IPv6 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
listening on IPv6 interfaces, port 53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
listening on IPv4 interface lo, 127.0.0.1#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
listening on IPv4 interface ens32, 10.73.100.31#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
generating session key for dynamic DNS
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
sizing zone task pool based on 6 zones
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
set up managed keys zone for view _default, file
'/var/named/dynamic/managed-keys.bind'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
bind-dyndb-ldap version 10.0 compiled at 18:06:06 Nov 11 2016,
compiler 4.8.5 20150623 (Red Hat 4.8.5-11)
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
option 'serial_autoincrement' is not supported, ignoring
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> ns-slapd[2596]:
GSSAPI server step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> ns-slapd[2596]:
GSSAPI server step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
GSSAPI client step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> ns-slapd[2596]:
GSSAPI server step 3
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
LDAP error: Invalid credentials: bind to LDAP server failed
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<http://id-management-2.internal.emerlyn.com> named-pkcs11[3948]:
couldn't establish connection in LDAP connection pool: permission
denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com
<ht

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

On 04.01.2017 22:21, Jeff Goddard wrote:
I don't want to hijack someone else's thread but I'm having what 
appears to be the same problem and have not seen a solution presented yet.


Here is the output of journalctl -xe after having tried to start named:

Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
loading configuration from '/etc/named.conf'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
reading built-in trusted keys from file '/etc/named.iscdlv.key'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
using default UDP/IPv4 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
using default UDP/IPv6 port range: [1024, 65535]
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
listening on IPv6 interfaces, port 53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
listening on IPv4 interface lo, 127.0.0.1#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
listening on IPv4 interface ens32, 10.73.100.31#53
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
generating session key for dynamic DNS
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
sizing zone task pool based on 6 zones
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: set 
up managed keys zone for view _default, file 
'/var/named/dynamic/managed-keys.bind'
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
bind-dyndb-ldap version 10.0 compiled at 18:06:06 Nov 11 2016, 
compiler 4.8.5 20150623 (Red Hat 4.8.5-11)
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
option 'serial_autoincrement' is not supported, ignoring
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 ns-slapd[2596]: GSSAPI 
server step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
GSSAPI client step 1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 ns-slapd[2596]: GSSAPI 
server step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
GSSAPI client step 2
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 ns-slapd[2596]: GSSAPI 
server step 3
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: LDAP 
error: Invalid credentials: bind to LDAP server failed
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
couldn't establish connection in LDAP connection pool: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
dynamic database 'ipa' configuration failed: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
loading configuration: permission denied
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 named-pkcs11[3948]: 
exiting (due to fatal error)
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 systemd[1]: 
named-pkcs11.service: control process exited, code=exited status=1
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 systemd[1]: Failed to 
start Berkeley Internet Name Domain (DNS) with native PKCS#11.

-- Subject: Unit named-pkcs11.service has failed
-- Defined-By: systemd
-- Support: 
http://lists.freedesktop.org/mailman/listinfo/systemd-devel 


--
-- Unit named-pkcs11.service has failed.
--
-- The result is failed.
Jan 04 15:48:42 id-management-2.internal.emerlyn.com 
 systemd[1]: 

Re: [Freeipa-users] Lookups Failing With AD Forwarder (and DNSSEC)

[Martin Basti]

On 04.01.2017 23:40, Jason B. Nance wrote:

Hello everyone,

I have a pair of FreeIPA 4.4.0 servers setup whose forwarders are each set to 
an Active Directory domain controller.  When a client attempts to lookup any 
DNS record other than those to which FreeIPA is authoritative the client 
reports NXDOMAIN and the FreeIPA server has the following in its logs:

(first lookup)
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no 
valid RRSIG) resolving 'zone/DS/IN': 10.48.8.18#53
Jan 04 16:05:21 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error (no 
valid DS) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 10.48.8.18#53

(subsequent lookups)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: validating 
@0x7f7a40983ea0: sl1mmgpwtdc0001.tkc.gen.zone A: bad cache hit (zone/DS)
Jan 04 16:10:57 sl1mmgplidm0001.ipa.tkc.gen.zone named-pkcs11[1632]: error 
(broken trust chain) resolving 'sl1mmgpwtdc0001.tkc.gen.zone/A/IN': 
10.48.8.18#53

In my case, ipa.tkc.gen.zone is served by FreeIPA and tkc.gen.zone is served by 
AD (as is gen.zone).  10.48.8.18 is an AD domain controller for tkc.gen.zone 
(and the forwarder the FreeIPA servers are pointed at).

I've tried "rndc flush" and "rndc flushname ." on the FreeIPA boxes.  We've 
tried both NSEC3 and NSEC.

Anyone have guidance as to what may be going on?

Thanks,

j



Hello,

you use non-existent TLD domain or TLD domain doesn't have DS record of 
your zone, so this is expected behavior for DNSSEC considered as attack. 
You have to disable DNSSEC validation on all IPA DNS servers in 
/etc/named.conf in first case or fix incorrect/missing DS record in 
second case.


The 'zone.' is registered TLD, so if you own it you have probably 
missing DS record in path, thus broken trust chain.

If you don't own the TLD, you shouldn't use it at all.

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] LDAP replication conflicts, but no apparent data damage

[Martin Basti]

Then you have to update cn=ipaservers entry with correct values and 
remove the others



On 04.01.2017 14:27, dan.finkelst...@high5games.com wrote:


Yes, along with two name-conflicted "duplicates":

id:image001.jpg@01D1C26F.0E28FA60 <http://www.high5games.com/>

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com <mailto:dan.finkelst...@h5g.com>_| 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com <http://www.high5games.com/>

Play High 5 Casino <https://apps.facebook.com/highfivecasino/> and 
Shake the Sky <https://apps.facebook.com/shakethesky/>


Follow us on: Facebook <http://www.facebook.com/high5games>, Twitter 
<https://twitter.com/High5Games>, YouTube 
<http://www.youtube.com/High5Games>, Linkedin 
<http://www.linkedin.com/company/1072533?trk=tyah>


//

/This message and any attachments may contain confidential or 
privileged information and are only for the use of the intended 
recipient of this message. If you are not the intended recipient, 
please notify the sender by return email, and delete or destroy this 
and all copies of this message and all attachments. Any unauthorized 
disclosure, use, distribution, or reproduction of this message or any 
attachments is prohibited and may be unlawful./


*From: *Martin Basti <mba...@redhat.com>
*Date: *Wednesday, January 4, 2017 at 06:28
*To: *Dan Finkelstein <dan.finkelst...@high5games.com>, 
"freeipa-users@redhat.com" <freeipa-users@redhat.com>
*Subject: *Re: [Freeipa-users] LDAP replication conflicts, but no 
apparent data damage


Probably entries already exists

for example foripaserversdo you have following entry 
cn=ipaservers,cn=hostgroups,cn=accounts,dc=test,dc=local  on the replica?


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] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3

[Martin Basti]

On 30.12.2016 11:54, Martin Basti wrote:


Hello,

The first half of the first issue is this bug: 
https://fedorahosted.org/freeipa/ticket/6226


you have to enable SSL on server manually after installation


The second half of the first issue shouldn't be related to ticket 
above, but I don't know more details I'll leave this for IPA CA gurus



The second issue is unrelated to certificates, I believe that 
something in dirsrv causes this unusual behavior. I saw this before 
with other users.


* both no such entry for HTTP principal, or for topology plugin are 
the same issue


* all users have this issue with CA-less installation, but not always 
reproducible, I'm not sure if there can be a step in CA-less install 
that can cause this


* entries are in database (were added previously by installer) but 
during installation the search failed with no such entry, ldapsearch 
after installation works


* in access log SRCH is before ADD operation, but this is against the 
steps in installer, entry is added first and even installer failed 
hard so there is no way how to add it after failure caused by not 
found error.


[29/Dec/2016:10:33:02.775715491 +] conn=16 op=1 SRCH 
base="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
  scope=0 filter="(objectClass=*)" attrs=ALL
[29/Dec/2016:10:33:02.775892719 +] conn=16 op=1 RESULT err=32 tag=101 
nentries=0 etime=0
This caused installation failure (IMO - there is no more SRCH operation for 
HTTP principal in log) ^^
..
[29/Dec/2016:10:33:05.487917960 +] conn=17 op=10 ADD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.492213776 +] conn=17 op=10 RESULT err=0 tag=105 
nentries=0 etime=0 csn=5864e6530004
[29/Dec/2016:10:33:05.492372184 +] conn=17 op=11 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.494649080 +] conn=17 op=11 RESULT err=0 tag=103 
nentries=0 etime=0 csn=5864e65300010004
[29/Dec/2016:10:33:05.494816357 +] conn=17 op=12 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
These were added after failure ??? ^

I need a DS guru assistance to resolve this :)
Martin^2
Ticket for this issue has been opened 
https://fedorahosted.org/freeipa/ticket/6575 Martin^2

On 29.12.2016 19:13, Peter Pakos wrote:

Access log: https://files.pakos.uk/access.txt
Error log: https://files.pakos.uk/ipareplica-install.log.txt
I hope it helps.
On 29 December 2016 at 12:52, Peter Pakos <pe...@pakos.uk 
<mailto:pe...@pakos.uk>> wrote:


Hi guys,
I'm facing yet another problem with CA-less install of FreeIPA
replica and 3rd party SSL certificate.
Few days ago I deployed a new CA-less server (ipa02) by running
the following command:

ipa-server-install \   -r PAKOS.UK <http://PAKOS.UK> \   -n
pakos.uk <http://pakos.uk> \   -p 'password' \   -a
'password' \   --mkhomedir \   --setup-dns \  
--no-forwarders \   --no-dnssec-validation \  
--dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \  
--http-pin='' \   --http-cert-name=AlphaWildcardIPA \  
--idstart=1000


This server appears to be working OK.
Then yesterday I deployed a client (ipa01):

ipa-client-install \   -p admin \   -w 'password' \   --mkhomedir

Next, I promoted it to IPA server:

ipa-replica-install \   -w 'password' \   --mkhomedir \  
--setup-dns \   --no-forwarders \   --no-dnssec-validation \
  --dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \   --dirsrv-cert-name=AlphaWildcardIPA \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \  
--http-pin='' \   --http-cert-name=AlphaWildcardIPA


After it finished, I've noticed that dirsrv wasn't running on
port 636 on ipa01.
Further investigation revealed that the SSL wildcard certificate
(AlphaWildcardIPA) wasn't installed in dirsrv DB and CA
certificates were named oddly (CA 1 and CA 2):

[root@ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate
Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA
u,u,u CA 1 ,, CA 2 C,, [root@ipa01 ~]# certutil -L -d
/etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa ,,
AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,,

This is what I found in the error log:

[29/Dec/2016:01:43:58.852745536 +] 389-Directory/1.3.5.10
<http://1.3.5.10> B2016.341. starting up
[29/Dec/2016:01:43:58.867642515 +] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match [29/Dec/2

Re: [Freeipa-users] Broken dirsrv and SSL certificate in CA-less install of FreeIPA 4.4 on CentOS 7.3

[Martin Basti]

Hello,

The first half of the first issue is this bug: 
https://fedorahosted.org/freeipa/ticket/6226


you have to enable SSL on server manually after installation


The second half of the first issue shouldn't be related to ticket above, 
but I don't know more details I'll leave this for IPA CA gurus



The second issue is unrelated to certificates, I believe that something 
in dirsrv causes this unusual behavior. I saw this before with other users.


* both no such entry for HTTP principal, or for topology plugin are the 
same issue


* all users have this issue with CA-less installation, but not always 
reproducible, I'm not sure if there can be a step in CA-less install 
that can cause this


* entries are in database (were added previously by installer) but 
during installation the search failed with no such entry, ldapsearch 
after installation works


* in access log SRCH is before ADD operation, but this is against the 
steps in installer, entry is added first and even installer failed hard 
so there is no way how to add it after failure caused by not found error.


[29/Dec/2016:10:33:02.775715491 +] conn=16 op=1 SRCH 
base="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
 scope=0 filter="(objectClass=*)" attrs=ALL
[29/Dec/2016:10:33:02.775892719 +] conn=16 op=1 RESULT err=32 tag=101 
nentries=0 etime=0


This caused installation failure (IMO - there is no more SRCH operation for 
HTTP principal in log) ^^
..
[29/Dec/2016:10:33:05.487917960 +] conn=17 op=10 ADD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.492213776 +] conn=17 op=10 RESULT err=0 tag=105 
nentries=0 etime=0 csn=5864e6530004
[29/Dec/2016:10:33:05.492372184 +] conn=17 op=11 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
[29/Dec/2016:10:33:05.494649080 +] conn=17 op=11 RESULT err=0 tag=103 
nentries=0 etime=0 csn=5864e65300010004
[29/Dec/2016:10:33:05.494816357 +] conn=17 op=12 MOD 
dn="krbprincipalname=HTTP/ipa01.pakos...@pakos.uk,cn=services,cn=accounts,dc=pakos,dc=uk"
These were added after failure ??? ^


I need a DS guru assistance to resolve this :)
Martin^2

On 29.12.2016 19:13, Peter Pakos wrote:

Access log: https://files.pakos.uk/access.txt
Error log: https://files.pakos.uk/ipareplica-install.log.txt
I hope it helps.
On 29 December 2016 at 12:52, Peter Pakos > wrote:


Hi guys,
I'm facing yet another problem with CA-less install of FreeIPA
replica and 3rd party SSL certificate.
Few days ago I deployed a new CA-less server (ipa02) by running
the following command:

ipa-server-install \   -r PAKOS.UK  \   -n
pakos.uk  \   -p 'password' \   -a 'password'
\   --mkhomedir \   --setup-dns \   --no-forwarders \  
--no-dnssec-validation \  
--dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \   --http-pin=''

\   --http-cert-name=AlphaWildcardIPA \   --idstart=1000

This server appears to be working OK.
Then yesterday I deployed a client (ipa01):

ipa-client-install \   -p admin \   -w 'password' \   --mkhomedir

Next, I promoted it to IPA server:

ipa-replica-install \   -w 'password' \   --mkhomedir \  
--setup-dns \   --no-forwarders \   --no-dnssec-validation \  
--dirsrv-cert-file=/root/ssl/star.pakos.uk.pfx \  
--dirsrv-pin='' \   --dirsrv-cert-name=AlphaWildcardIPA \  
--http-cert-file=/root/ssl/star.pakos.uk.pfx \   --http-pin=''

\   --http-cert-name=AlphaWildcardIPA

After it finished, I've noticed that dirsrv wasn't running on port
636 on ipa01.
Further investigation revealed that the SSL wildcard certificate
(AlphaWildcardIPA) wasn't installed in dirsrv DB and CA
certificates were named oddly (CA 1 and CA 2):

[root@ipa01 ~]# certutil -L -d /etc/httpd/alias/ Certificate
Nickname Trust Attributes SSL,S/MIME,JAR/XPI AlphaWildcardIPA
u,u,u CA 1 ,, CA 2 C,, [root@ipa01 ~]# certutil -L -d
/etc/dirsrv/slapd-PAKOS-UK/ Certificate Nickname Trust Attributes
SSL,S/MIME,JAR/XPI GlobalSign Root CA - GlobalSign nv-sa ,,
AlphaSSL CA - SHA256 - G2 - GlobalSign nv-sa C,,

This is what I found in the error log:

[29/Dec/2016:01:43:58.852745536 +] 389-Directory/1.3.5.10
 B2016.341. starting up
[29/Dec/2016:01:43:58.867642515 +] default_mr_indexer_create:
warning - plugin [caseIgnoreIA5Match] does not handle
caseExactIA5Match [29/Dec/2016:01:43:58.889866051 +]
schema-compat-plugin - scheduled schema-compat-plugin tree scan in
about 5 seconds after the server startup!
[29/Dec/2016:01:43:58.905267535 +] NSACLPlugin - The ACL
target 

Re: [Freeipa-users] Using Privacyidea with FreeIPA - part 1/n

[Martin Basti]

Hello, I have a few comments/questions related to HOTP inline


On 28.12.2016 13:54, Jochen Hein wrote:

[ This mail sets the stage for more parts, which will get into technical
details. Comments or suggestions are welcome, possibly we should add
refined texts in the relevant wikis/documentations. - Jochen ]

When I first looked at privacyidea I was quite unsure how it would
integrate into my existing network and what tokens and applications I
would use privacyidea for. After lots of thought and experiments I now
think I have a useful scenario to work with. I run a family network with
a local mail server (Kolab), webmail, ssh, and VPN access and think the
structure might also work for small or medium offices too.

Originally I had the userstore in Kolab's LDAP server which I wanted
to use for more applications, e.g. Linux logins.  pam_ldap and
pam_ldapd could access the userstore in LDAP, but require that the
server is available.  How should that work for a roadwarrior setup?
I've found sssd, but never had time to play with it.  So that idea
never got off the ground.

Former tries with Kerberos/LDAP have not been successful, but once I
found FreeIPA[1] I was kind of hooked.  FreeIPA has:

- LDAP as backend (e.g. userstore)
- a versatile command line interface ("ipa")
- a useful web interface
- client software to join a Linux machine into the FreeIPA realm
- sssd for clients by default
- works "out of the box"

If you need a central userstore with host based access control, SSO
and lots of other features - I can really recommend it.

I'll discuss later, what features I use with which software and why.

The latest FreeIPA version has some OTP features included, for example
Yubikeys or FreeOTP tokens.  So, why would you want to use another OTP
provider than FreeIPA?  I use (and plan to extend the usage) Yubikey
tokens. Since the Yubikeys only have two slots[2], we need to decide
what we want to use the slots for.

I want to have the following applications running with my Yubikeys:

- Second Factor for my keepass file
- Second Factor for login/ssh (later webmail access)
- Second Factor for sudo authentication

I've settled for the following usage of the slots:

* Slot 1: This is a (reprogrammed) Yubico-AES token, which
   authenticates against Privacyides yubico mode instead of Yubicos
   cloud server.

   Why Yubico and not HOTP or TOTP?

   Here FreeIPA fails for me: Yubikey can't do TOTP, HOTP token can get
   out of sync, when we use them for local authentication, FreeIPA and
   Kolab (each application has a count, which needs to be "in near
   sync" with the counter in the Yubikey. I wouldn't trust such a
   setup.)


AFAIK this is security feature to have "Window of allowed tokens" and 
counter is essential for HOTP, 
https://tools.ietf.org/html/rfc4226#section-7.2


   But providing access to a Yubico Token via privacyidea works for all
   cases I have in mind.


How they are checking the valid tokes if they don't use its counter?



* Slot 2: Yubikey Challenge Response

   I use that as a second factor for my keepass file with
   keechallenge. The second application is my LUKS encrypted Laptop with
   privacyidea's privacyidea-luks-assign help. With pam_yubico I restrict
   access to Laptops with a second factor, without the need for a central
   authentication server[3]. For the laptops (local login) I skip
   entering a sudo password when a yubico is present and authenticated.

   Since there is no token count, the token will not get
   out of sync.

For my local net u2f didn't seem useful, but I'll use it for remote
services.

I consider that design more secure than using only a password, but
also more convenient. Let's see how far that will take us.

[1] http://www.freeipa.org
[2] How does that relate to PIV, U2F, and smart card features?
[3] pam_python+privacyidea might help, but the packages are not in
distro repositories and even more of a niche product than pam_yubico.

The rest of this series expects that the PI host is enrolled in IPA.
On Debian/Ubuntu systems, add the ca.crt to the local ca store:

ln -s /etc/ipa/ca.crt /usr/local/share/ca-certificates update-ca-certificates




--
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] DNS reverse zone is not managed by this server

[Martin Basti]

Great, you are welcome :)


On 27.12.2016 13:41, Maciej Drobniuch wrote:

Martin,

Your troubleshooting style put me on the right track.

The alternative DNS servers had Ipv6  records that did not resolv 
properly.


After deleting those records adding A records (with reverse PTR check) 
and adding host works fine. The PTR record is created in the GUI and 
works fine.


Thank you very much for your time and help with this!

Cheers!
M.

On Tue, Dec 27, 2016 at 1:35 PM, Maciej Drobniuch 
<m...@collective-sense.com <mailto:m...@collective-sense.com>> wrote:


# dig soa  0.0.10.in-addr.arpa.

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> soa 0.0.10.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60690
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3,
ADDITIONAL: 8

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INSOA

;; ANSWER SECTION:
0.0.10.in-addr.arpa.86400INSOAfreeipa1.cs.int
<http://freeipa1.cs.int>. hostmaster.cs.int
<http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int <http://freeipa1.cs.int>.
0.0.10.in-addr.arpa.86400INNSfreeipa2.cs.int <http://freeipa2.cs.int>.
0.0.10.in-addr.arpa.86400INNSkrkfreeipa.cs.int
<http://krkfreeipa.cs.int>.

;; ADDITIONAL SECTION:
freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200
freeipa2.cs.int <http://freeipa2.cs.int>.1200INA10.0.1.200
krkfreeipa.cs.int <http://krkfreeipa.cs.int>.1200INA10.0.2.6

;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: wto gru 27 07:33:41 EST 2016
;; MSG SIZE  rcvd: 333


On Tue, Dec 27, 2016 at 1:28 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:

I just noticed previously you sent wrong dig, I need

dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype




On 27.12.2016 13:21, Maciej Drobniuch wrote:

# python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print
a.rrset.name <http://a.rrset.name>'
0.0.10.in-addr.arpa.

On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY:
1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int
<http://freeipa1.cs.int>. hostmaster.cs.int
<http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111



Hmm, this query doesn't contain ANSWER section, that may
be reason why python-dns failed.

could you check with:

python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN");
print a.rrset.name <http://a.rrset.name>'




On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti
    <mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti
    <mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>>
wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR
record. I've added it manually to the
zone and it's working.


I was as

Re: [Freeipa-users] List SPAM

[Martin Basti]

On 27.12.2016 13:22, Outback Dingo wrote:

Im still getting nude porn spam emails and pics from a user

Kimi Rachel 



It is not a user, it is a SPAM bot mining public archives. We don't have 
any control about it we can just un-publish archives (tested, spam 
stopped after that) but they contain a lot of information for users.


JFTR the email is changing.

--
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] DNS reverse zone is not managed by this server

[Martin Basti]

I just noticed previously you sent wrong dig, I need

dig 0.0.10.in-addr.arpa.  SOA  instead of the A rtype




On 27.12.2016 13:21, Maciej Drobniuch wrote:
# python -c 'from dns import resolver; a = 
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print 
a.rrset.name <http://a.rrset.name>'

0.0.10.in-addr.arpa.

On Tue, Dec 27, 2016 at 1:09 PM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:




On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1,
ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int
<http://freeipa1.cs.int>. hostmaster.cs.int
<http://hostmaster.cs.int>. 1482653944 3600 900 1209600 3600

;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111



Hmm, this query doesn't contain ANSWER section, that may be reason
why python-dns failed.

could you check with:

python -c 'from dns import resolver; a =
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print
a.rrset.name <http://a.rrset.name>'




On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:



    On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



    On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've
added it manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is
nothing secret about reverse zone name from private
address space

what returns this command on server?
python -c 'import netaddr; from dns import
resolver; ip = netaddr.IPAddress("10.0.0.165");
revn = ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver;
ip = netaddr.IPAddress("10.0.0.165"); revn =
ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone,
what is supposed to be authoritative zone for that
record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the
dns server for the internal zone?
As far I understood this is not a "access rights issue".
It's a DNS PTR resolution problem with python(ipa's using
python) ?


It doesn't care about resolver, python-dns is checking SOA
records, it removes labels from left and tries to find best
match zone

what returns dig 0.0.10.in-addr.arpa.  SOA ?









2. The problem exists while adding host entries or
A records with "create reverse" option.

That's why I asked to run dig, the code uses DNS
system to determine zone.


3. If I'll bind a host with ipa-client-install the
PTR record gets created in the reverse zone and it
works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not
see the local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs.
(I've manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.

Re: [Freeipa-users] DNS reverse zone is not managed by this server

[Martin Basti]

On 27.12.2016 13:04, Maciej Drobniuch wrote:

$ dig 0.0.10.in-addr.arpa

; <<>> DiG 9.10.3-P4-Ubuntu <<>> 0.0.10.in-addr.arpa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14232
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;0.0.10.in-addr.arpa.INA

;; AUTHORITY SECTION:
0.0.10.in-addr.arpa.3600INSOAfreeipa1.cs.int <http://freeipa1.cs.int>. 
hostmaster.cs.int <http://hostmaster.cs.int>. 1482653944 3600 900 
1209600 3600


;; Query time: 197 msec
;; SERVER: 10.0.0.200#53(10.0.0.200)
;; WHEN: Tue Dec 27 13:02:24 CET 2016
;; MSG SIZE  rcvd: 111


Hmm, this query doesn't contain ANSWER section, that may be reason why 
python-dns failed.


could you check with:

python -c 'from dns import resolver; a = 
resolver.query("0.0.10.in-addr.arpa.", "SOA", "IN"); print a.rrset.name'



On Tue, Dec 27, 2016 at 12:24 PM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:




On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:



On 22.12.2016 10:57, Maciej Drobniuch wrote:

    Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added
it manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing
secret about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip
= netaddr.IPAddress("10.0.0.165"); revn =
ip.reverse_dns; print revn; print
resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns;
print revn; print resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is
supposed to be authoritative zone for that record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the dns
server for the internal zone?
As far I understood this is not a "access rights issue". It's a
DNS PTR resolution problem with python(ipa's using python) ?


It doesn't care about resolver, python-dns is checking SOA
records, it removes labels from left and tries to find best match zone

what returns dig 0.0.10.in-addr.arpa.  SOA ?









2. The problem exists while adding host entries or A
records with "create reverse" option.

That's why I asked to run dig, the code uses DNS system
to determine zone.


3. If I'll bind a host with ipa-client-install the PTR
record gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see
the local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs.
(I've manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,
ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
<http://prdfrmprb01.cs.int>.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int
<http://freeipa1.cs.int>.



This authority section looks suspicious, I would expect
something like 0.0.10.in-addr.arpa.

Back to question about your reverse zones.

I've intentionally hid our internal ip space, sorry, good catch
my finger has slipped :).


So is the 0.0.10.in-

Re: [Freeipa-users] IPA Servers out of sync - DNS records

[Martin Basti]

On 27.12.2016 12:55, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 6:47 AM, Martin Basti <mba...@redhat.com> wrote:


On 27.12.2016 12:40, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti <mba...@redhat.com> wrote:


On 27.12.2016 00:25, Outback Dingo wrote:

Seems my secondary ipa server is somehow out of sync with the master,
is there any way to force a sync update ?


Can you elaborate more?

What exactly from DNS records is out of sync?

Martin


it appears as though at least one A record is missing there might be
more but thats the first i noticed



Can you please search for replication conflicts

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

and do you have any replication errors in /var/log/dirsrv/slapd-*/errors
log on servers?

Martin

from the master ipa

[root@ipa dingo]# cat /var/log/dirsrv/slapd-*/errors
389-Directory/1.3.4.0 B2016.215.1556
ipa.optimcloud.com:636 (/etc/dirsrv/slapd-OPTIMCLOUD-COM)

[20/Dec/2016:22:38:51 -0500] - SSL alert: Configured NSS Ciphers
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_GCM_SHA384: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_256_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_GCM_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_AES_128_CBC_SHA256: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] - SSL alert:
TLS_RSA_WITH_SEED_CBC_SHA: enabled
[20/Dec/2016:22:38:51 -0500] SSL Initialization - Configured SSL
version range: min: TLS1.0, max: TLS1.2
[20/Dec/2016:22:38:51 -0500] - 389-Directory/1.3.4.0 B2016.215.1556 starting up
[20/Dec/2016:22:38:51 -0500] - WARNING: changelog: entry cache size
2097152B is less than db size 4169728B; 

Re: [Freeipa-users] IPA Servers out of sync - DNS records

[Martin Basti]

On 27.12.2016 12:40, Outback Dingo wrote:

On Tue, Dec 27, 2016 at 5:59 AM, Martin Basti <mba...@redhat.com> wrote:


On 27.12.2016 00:25, Outback Dingo wrote:

Seems my secondary ipa server is somehow out of sync with the master,
is there any way to force a sync update ?


Can you elaborate more?

What exactly from DNS records is out of sync?

Martin


it appears as though at least one A record is missing there might be
more but thats the first i noticed



Can you please search for replication conflicts

https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html

and do you have any replication errors in 
/var/log/dirsrv/slapd-*/errors  log on servers?


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] DNS reverse zone is not managed by this server

[Martin Basti]

On 27.12.2016 12:07, Maciej Drobniuch wrote:

Hi Martin!

Thank you for your time!

On Thu, Dec 22, 2016 at 1:41 PM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:




On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:



On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it
manually to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing
secret about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'
165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is
supposed to be authoritative zone for that record in your system?
How do your reverse zones look?

I have the reverse zone added.
0.0.10.in-addr.arpa.

Do you know maybe how python/ipa is determining what's the dns server 
for the internal zone?
As far I understood this is not a "access rights issue". It's a DNS 
PTR resolution problem with python(ipa's using python) ?


It doesn't care about resolver, python-dns is checking SOA records, it 
removes labels from left and tries to find best match zone


what returns dig 0.0.10.in-addr.arpa.  SOA ?








2. The problem exists while adding host entries or A records
with "create reverse" option.

That's why I asked to run dig, the code uses DNS system to
determine zone.


3. If I'll bind a host with ipa-client-install the PTR
record gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see the
local reverse zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've
manually created the ptr)

# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1,
ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int
<http://prdfrmprb01.cs.int>.

;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int
<http://freeipa1.cs.int>.



This authority section looks suspicious, I would expect something
like 0.0.10.in-addr.arpa.

Back to question about your reverse zones.

I've intentionally hid our internal ip space, sorry, good catch my 
finger has slipped :).


So is the 0.0.10.in-addr.arpa. an authoritative zone? Or what dig 
returned in authority section.






;; ADDITIONAL SECTION:
freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE  rcvd: 124



Martin




Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti
<mba...@redhat.com <mailto:mba...@redhat.com>> wrote:

Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS
reverse zone in-addr.arpa. for IP address 10.0.0.165 is
not managed by this server"


IPA failed to get correct reverse zone, can you try dig
-x 10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse
zone - all OK

While adding a new host,  the A record is being created
but the PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to
rei

Re: [Freeipa-users] Unable to add attributes to default user schema

[Martin Basti]

On 26.12.2016 20:51, Carlos Raúl Laguna wrote:

Hello everyone,

I am trying to add a new attribute ¨mailQuota¨ to the default user 
schema, so far i add the objectclass mailrecipient to the default user 
objectclasses which contain this specific atribute but so far i only 
capable to add the attribute manually with user-mod 
--addattr=mailQuota=102400 but when invoke config-mod 
--addattr=mailQuota=102400 i get ipa: ERROR: attribute "mailQuota" not 
allowed. Any way to get around this, also does 
https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf is 
still relevant for freeipa 4.3.2 ?


Thanks in advance



Hello,

this is not right,
config-mod --addattr=mailQuota=102400

this is not a way how to set a new attr with default value for users, to 
set custom value you need to use custom user_add pre-callback, slide 17


HTH
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] Still unclear about relation between IPA DNS domain and company DNS domain.

[Martin Basti]

On 22.12.2016 17:53, Brian Candler wrote:

On 20/12/2016 08:07, Petr Spacek wrote:
I've tried to clarify things in man pages and on web as well. Please 
have a
look to changes and let us know if it is better or not, and 
preferably what

can be improved and in which way

The modified deployment page is here:
http://www.freeipa.org/page/Deployment_Recommendations

Man page changes and changes in description of installer options are 
here:

https://github.com/freeipa/freeipa/pull/352


Thank you for working on this.

This is getting clearer, but I would like to expand a little more.

(1) This introduces a concept of an "IPA Primary Domain".  Is that 
just the DNS domain which holds the SRV records which point to the 
realm's kerberos/ldap servers, or does it have any other function? In 
other words, what other effects would there be from choosing a 
different IP Primary Domain?


it holds SRV records, A/ records for CA

LDAP tree is constructed from the domain (cn=accounts,dc=example,dc=com)



Let me give a specific example.

- IPA server hostname is ipa.foo.example.com
- I want to create kerberos realm BAR.EXAMPLE.COM

Which IPA primary domain should I choose?

The expected place for SRV records for realm BAR.EXAMPLE.COM would be 
in the DNS under domain bar.example.com.  So I'm thinking that 
"--domain bar.example.com" is the right thing - and can't think why 
you'd ever want to do anything else.





Then use bar.example.com, IPA servers can have names outside the IPA 
domain name space.


Different people wants different things, that's why the option is there.



(2) I'm trying to work out how --domain, --realm, --server and 
systemhostname influence each other, if one or more is not provided.


For ipa-server-install, testing suggests:

* --domain defaults to the domain part of the system hostname
* --realm defaults to the uppercased --domain
* (--server is obviously itself :-)

For ipa-client-install it seems a bit more complex. Based on the 
manpage, I believe the sequence is something like this:


* If --domain is not specified, then it's the domain from the system 
hostname
* If --server is not specified, then it hunts for servers based on the 
--domain (looking in that domain and its parents until suitable SRV 
records are found)
* If --realm is not specified, then it sends a query to the 
--server(s) to ask what realm they are in


But the manpage says you can specify both --server and --domain:

  "Client  machine  can  also be configured without a DNS 
autodiscovery at all. When both
   --server and --domain options are used, client installer will 
use the specified server

   and  domain  directly."


Server and client can be in different DNS domains, that's probably why 
it has separate options.


I know that it is not clear how client determine domain and server, but 
there were more important things to fix, this may be improved in future.





In that case, I can't see what the --domain is used for here, if it's 
only purpose is to locate servers (and you've already told it which 
--server to use)


Thanks,

Brian.



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] DNS reverse zone is not managed by this server

[Martin Basti]

On 22.12.2016 10:57, Maciej Drobniuch wrote:

Hi Martin

Appreciate your help!

On Thu, Dec 22, 2016 at 10:48 AM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:




On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it manually
to the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing secret
about reverse zone name from private address space

what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip =
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print
revn; print resolver.zone_for_name(revn)'


# python -c 'import netaddr; from dns import resolver; ip = 
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; 
print resolver.zone_for_name(revn)'

165.0.0.10.in-addr.arpa.
in-addr.arpa.


It looks that python-dns failed to find proper zone, what is supposed to 
be authoritative zone for that record in your system?

How do your reverse zones look?





2. The problem exists while adding host entries or A records with
"create reverse" option.

That's why I asked to run dig, the code uses DNS system to
determine zone.


3. If I'll bind a host with ipa-client-install the PTR record
gets created in the reverse zone and it works

Ok

Manually creating the PTR record works fine as well.




4. The resolv.conf file has only the IPA server IP
addres/localhost added.


Have you changed it recently?

Yes, it pointed to outside 8.8.8.8, so the OS did not see the local 
reverse zone.
Now it's pointing to localhost. And I get dig the PTRs. (I've manually 
created the ptr)


# dig -x 10.0.0.165

; <<>> DiG 9.9.4-RedHat-9.9.4-38.el7_3 <<>> -x 10.0.0.165
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35592
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; E: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;165.0.0.10.in-addr.arpa.INPTR

;; ANSWER SECTION:
165.0.0.10.in-addr.arpa. 1200INPTRprdfrmprb01.cs.int 
<http://prdfrmprb01.cs.int>.


;; AUTHORITY SECTION:
1.0.10.in-addr.arpa.86400INNSfreeipa1.cs.int <http://freeipa1.cs.int>.



This authority section looks suspicious, I would expect something like 
0.0.10.in-addr.arpa.


Back to question about your reverse zones.


;; ADDITIONAL SECTION:
freeipa1.cs.int <http://freeipa1.cs.int>.1200INA10.0.0.200

;; Query time: 3 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: czw gru 22 04:51:23 EST 2016
;; MSG SIZE  rcvd: 124



Martin




Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com
<mailto:mba...@redhat.com>> wrote:

Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS
reverse zone in-addr.arpa. for IP address 10.0.0.165 is not
managed by this server"


IPA failed to get correct reverse zone, can you try dig -x
10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone
- all OK

While adding a new host,  the A record is being created but
the PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to reinstall
again because of problems with kerberos(probably dependencies).

Not sure what is the root cause of the issue.

VERSION: 4.4.0, API_VERSION: 2.213

CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar
6 11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Any help appreciated!
-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC







-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC





--
Best regards

Maciej Drobniuch
Network Security Engineer
2410 Camino Ramon, Suite 129
San Ramon, CA 94583


-- 
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] DNS reverse zone is not managed by this server

[Martin Basti]

On 22.12.2016 09:37, Maciej Drobniuch wrote:

Hi Martin

Thank you for reply.

1. The dig is returning proper PTR record. I've added it manually to 
the zone and it's working.


I was asking for SOA and zone name, IMO there is nothing secret about 
reverse zone name from private address space


what returns this command on server?
python -c 'import netaddr; from dns import resolver; ip = 
netaddr.IPAddress("10.0.0.165"); revn = ip.reverse_dns; print revn; 
print resolver.zone_for_name(revn)'



2. The problem exists while adding host entries or A records with 
"create reverse" option.

That's why I asked to run dig, the code uses DNS system to determine zone.

3. If I'll bind a host with ipa-client-install the PTR record gets 
created in the reverse zone and it works

Ok


4. The resolv.conf file has only the IPA server IP addres/localhost added.


Have you changed it recently?

Martin



Cheers!
M.

On Wed, Dec 21, 2016 at 5:43 PM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:


Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS reverse
zone in-addr.arpa. for IP address 10.0.0.165 is not managed by
this server"


IPA failed to get correct reverse zone, can you try dig -x
10.0.0.165 what will be in SOA answer?

What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone - all OK

While adding a new host,  the A record is being created but the
PTR fails with the message above.

Reinstalling centos+IPA worked once but I had to reinstall again
because of problems with kerberos(probably dependencies).

Not sure what is the root cause of the issue.

VERSION: 4.4.0, API_VERSION: 2.213

CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6
11:36:42 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Any help appreciated!
-- 
Best regards


Maciej Drobniuch
Network Security Engineer
Collective-sense LLC







--
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-sense LLC


-- 
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] DNS reverse zone is not managed by this server

[Martin Basti]

Hello all :)


On 20.12.2016 01:33, Maciej Drobniuch wrote:

Hi All!

I get the following message while adding a new hostname.

"The host was added but the DNS update failed with: DNS reverse zone 
in-addr.arpa. for IP address 10.0.0.165 is not managed by this server"


IPA failed to get correct reverse zone, can you try dig -x 10.0.0.165 
what will be in SOA answer?


What is the name of reverse zone you have on IPA DNS server?


Martin



The reverse zone is configured and working.
When I am manually adding the PTR record to the reverse zone - all OK

While adding a new host,  the A record is being created but the PTR 
fails with the message above.


Reinstalling centos+IPA worked once but I had to reinstall again 
because of problems with kerberos(probably dependencies).


Not sure what is the root cause of the issue.

VERSION: 4.4.0, API_VERSION: 2.213

CENTOS7 Linux freeipa1 3.10.0-229.el7.x86_64 #1 SMP Fri Mar 6 11:36:42 
UTC 2015 x86_64 x86_64 x86_64 GNU/Linux


Any help appreciated!
--
Best regards

Maciej Drobniuch
Network Security Engineer
Collective-sense LLC




-- 
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] Failed to promote ipa client to ipa replica

[Martin Basti]

On 20.12.2016 20:27, fay wang wrote:
Hi, I have no luck in promoting ipa client to ipa replica. In my 
replica system where ipa client is installed:


certutil -L -d /etc/dirsrv/slapd-

does not have Server-Cert.

Please help!

Thanks,
fay






Which commands did you used to promote replica?
Can you show us the output of that commands?

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

[Freeipa-users] [PTO] 2016-12-21 -- 2017-01-02

[Martin Basti]

Merry Christmas and Happy New Year 2017


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] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

On 19.12.2016 21:24, Brian J. Murrell wrote:

On Mon, 2016-12-19 at 17:26 +0100, Martin Basti wrote:

On 19.12.2016 13:19, Brian J. Murrell wrote:

On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote:

Hello,

could you recheck with SElinux in permissive mode?

Yeah, still happens even after doing:

# setenforce 0

Cheers,
b.

could you please kinit as service?


kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-
dnskeysyncd/$(hostname)

# kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab 
ipa-dnskeysyncd/server.example.com
# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: ipa-dnskeysyncd/server.example@example.com

Valid starting ExpiresService principal
19/12/16 15:20:20  20/12/16 15:20:20  krbtgt/example@example.com

Seems to have worked.  FWIW, I was not asked for any password.

Cheers,
b.




The password is the keytab file

So there are actually no issues with credentials, it needs more 
debugging, in past we have similar case but we haven't found the root 
cause why it doesn't have the right credentials after kinit. Are you 
willing to do more basic level code debugging?


BTW this is used only with DNSSEC feature. I you don't use DNSSEC 
signing you can ignore this failing service (ipactl start 
--ignore-service-failures)


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] ipa-dnskeysyncd not starting

[Martin Basti]

On 19.12.2016 17:51, Rob Verduijn wrote:
2016-12-19 17:06 GMT+01:00 Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>>:




On 19.12.2016 16:27, Rob Verduijn wrote:



2016-12-19 16:07 GMT+01:00 Rob Verduijn <rob.verdu...@gmail.com
<mailto:rob.verdu...@gmail.com>>:




2016-12-19 15:52 GMT+01:00 Petr Spacek <pspa...@redhat.com
<mailto:pspa...@redhat.com>>:

On 19.12.2016 14:07, Rob Verduijn wrote:
> Hello,
>
> I'm running ipa on centos 7.3 with the latest patches
applied.
>
> It seem to run fine however the ipa-dnskeysyncd keeps
failing to start and
> I keep seeing this message in my logs:
>
> ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind...
> python2[25663]: GSSAPI client step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25663]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: ipa : INFO  Commencing
sync process
> ipa-dnskeysyncd[25663]:
ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO
> Initial LDAP dump is done, sychronizing with ODS and BIND
> python2[25674]: GSSAPI client step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25674]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: Traceback (most recent call last):
> ipa-dnskeysyncd[25663]: File
"/usr/libexec/ipa/ipa-dnskeysyncd", line 110,
> in 
> ipa-dnskeysyncd[25663]: while
ldap_connection.syncrepl_poll(all=1,
> msgid=ldap_search):
> ipa-dnskeysyncd[25663]: File
> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py",
line 405, in
> syncrepl_poll
> ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone()
> ipa-dnskeysyncd[25663]: File
>
"/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 115,
> in syncrepl_refreshdone
> ipa-dnskeysyncd[25663]: self.hsm_replica_sync()
> ipa-dnskeysyncd[25663]: File
>
"/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 181,
> in hsm_replica_sync
> ipa-dnskeysyncd[25663]:
ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])
> ipa-dnskeysyncd[25663]: File
>
"/usr/lib/python2.7/site-packages/ipapython/ipautil.py",
line 494, in run
> ipa-dnskeysyncd[25663]: raise
CalledProcessError(p.returncode, arg_string,
> str(output))
> ipa-dnskeysyncd[25663]: subprocess.CalledProcessError:
Command
> '/usr/libexec/ipa/ipa-dnskeysync-replica' returned
non-zero exit status 1
> systemd[1]: ipa-dnskeysyncd.service: main process
exited, code=exited,
> status=1/FAILURE
> systemd[1]: Unit ipa-dnskeysyncd.service entered failed
state.
> systemd[1]: ipa-dnskeysyncd.service failed.
>
> for some reason the ipa-dnskeysyncd keeops crashing.
> Anybody know where to start looking for this one ?

Please raise the debug level so we can see something in
the logs:


http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data

<http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data>

--
Petr^2 Spacek

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
<https://www.redhat.com/mailman/listinfo/freeipa-users>
Go to http://freeipa.org for more info on the project


Hello,

The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf
do not exist on my system.
How to set debugging in this case ?

Rob


I've set the debug level in /etc/ipa/default.conf

now I get this output
 systemd[1]: ipa-dnskeysyncd.service: main process exit

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

On 19.12.2016 13:19, Brian J. Murrell wrote:

On Mon, 2016-12-19 at 09:42 +0100, Martin Basti wrote:

Hello,

could you recheck with SElinux in permissive mode?

Yeah, still happens even after doing:

# setenforce 0

Cheers,
b.


could you please kinit as service?


kinit -kt /etc/ipa/dnssec/ipa-dnskeysyncd.keytab ipa-dnskeysyncd/$(hostname)


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] ipa-dnskeysyncd not starting

[Martin Basti]

On 19.12.2016 16:27, Rob Verduijn wrote:



2016-12-19 16:07 GMT+01:00 Rob Verduijn >:





2016-12-19 15:52 GMT+01:00 Petr Spacek >:

On 19.12.2016 14:07, Rob Verduijn wrote:
> Hello,
>
> I'm running ipa on centos 7.3 with the latest patches applied.
>
> It seem to run fine however the ipa-dnskeysyncd keeps
failing to start and
> I keep seeing this message in my logs:
>
> ipa-dnskeysyncd[25663]: ipa : INFO LDAP bind...
> python2[25663]: GSSAPI client step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25663]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25663]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: ipa : INFO Commencing
sync process
> ipa-dnskeysyncd[25663]:
ipa.ipapython.dnssec.keysyncer.KeySyncer: INFO
> Initial LDAP dump is done, sychronizing with ODS and BIND
> python2[25674]: GSSAPI client step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 1
> python2[25674]: GSSAPI client step 1
> ns-slapd[2569]: GSSAPI server step 2
> python2[25674]: GSSAPI client step 2
> ns-slapd[2569]: GSSAPI server step 3
> ipa-dnskeysyncd[25663]: Traceback (most recent call last):
> ipa-dnskeysyncd[25663]: File
"/usr/libexec/ipa/ipa-dnskeysyncd", line 110,
> in 
> ipa-dnskeysyncd[25663]: while
ldap_connection.syncrepl_poll(all=1,
> msgid=ldap_search):
> ipa-dnskeysyncd[25663]: File
> "/usr/lib64/python2.7/site-packages/ldap/syncrepl.py", line
405, in
> syncrepl_poll
> ipa-dnskeysyncd[25663]: self.syncrepl_refreshdone()
> ipa-dnskeysyncd[25663]: File
>
"/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 115,
> in syncrepl_refreshdone
> ipa-dnskeysyncd[25663]: self.hsm_replica_sync()
> ipa-dnskeysyncd[25663]: File
>
"/usr/lib/python2.7/site-packages/ipapython/dnssec/keysyncer.py",
line 181,
> in hsm_replica_sync
> ipa-dnskeysyncd[25663]:
ipautil.run([paths.IPA_DNSKEYSYNCD_REPLICA])
> ipa-dnskeysyncd[25663]: File
> "/usr/lib/python2.7/site-packages/ipapython/ipautil.py",
line 494, in run
> ipa-dnskeysyncd[25663]: raise
CalledProcessError(p.returncode, arg_string,
> str(output))
> ipa-dnskeysyncd[25663]: subprocess.CalledProcessError: Command
> '/usr/libexec/ipa/ipa-dnskeysync-replica' returned non-zero
exit status 1
> systemd[1]: ipa-dnskeysyncd.service: main process exited,
code=exited,
> status=1/FAILURE
> systemd[1]: Unit ipa-dnskeysyncd.service entered failed state.
> systemd[1]: ipa-dnskeysyncd.service failed.
>
> for some reason the ipa-dnskeysyncd keeops crashing.
> Anybody know where to start looking for this one ?

Please raise the debug level so we can see something in the logs:


http://www.freeipa.org/page/Troubleshooting#ipa_command_crashes_or_returns_no_data



--
Petr^2 Spacek

--
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


Hello,

The file /etc/ipa/ipa.conf or the file /etc/ipa/server.conf do not
exist on my system.
How to set debugging in this case ?

Rob


I've set the debug level in /etc/ipa/default.conf

now I get this output
 systemd[1]: ipa-dnskeysyncd.service: main process exited, 
code=exited, status=1/FAILURE

 systemd[1]: Unit ipa-dnskeysyncd.service entered failed state.
 systemd[1]: ipa-dnskeysyncd.service failed.
 systemd[1]: ipa-dnskeysyncd.service holdoff time over, scheduling 
restart.

 systemd[1]: Started IPA key daemon.
 systemd[1]: Starting IPA key daemon...
 ipa-dnskeysyncd[30568]: ipa : INFO LDAP bind...
 python2[30568]: GSSAPI client step 1
 python2[30568]: GSSAPI client step 1
 ns-slapd[26744]: GSSAPI server step 1
 python2[30568]: GSSAPI client step 1
 ns-slapd[26744]: GSSAPI server step 2
 python2[30568]: GSSAPI client step 2
 ns-slapd[26744]: GSSAPI server step 3
 ipa-dnskeysyncd[30568]: ipa : INFO Commencing sync process
 ipa-dnskeysyncd[30568]: ipa.ipapython.dnssec.keysyncer.KeySyncer: 
INFO Initial LDAP dump is done, sychronizing with ODS 

Re: [Freeipa-users] ipa-dnskeysyncd ipa : ERROR Login to LDAP server failed: {'desc': 'Invalid credentials'}

[Martin Basti]

On 17.12.2016 19:30, Brian J. Murrell wrote:

On Fri, 2016-12-16 at 22:53 -0500, Brian J. Murrell wrote:

Hi,

After upgrading to EL 7.3 which included an upgrade of IPA from
4.2.0-
15.0.1.el7.centos.19 to 4.4.0-14.el7.centos I'm getting:

22:01:00 ipa-dnskeysyncd ipa : INFO LDAP bind...
22:01:00 ipa-dnskeysyncd ipa : ERRORLogin to LDAP server

I wonder if this is related:

https://bugzilla.redhat.com/show_bug.cgi?id=1405716
SELinux is preventing /usr/bin/python2.7 from read access on the file
unix.

It has started to show up as of this IPA upgrade also.

Cheers,
b.




Hello,

could you recheck with SElinux in permissive mode?

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] DNS search timeouts and incomplete results

[Martin Basti]

Receiving huge list of entries is not a cheap operation, that's why 
there is a default max limit set to 100/2000 entries. You have to count 
with that. Maybe direct AXFR from DNS may be more suitable for you, to 
get the complete list of DNS records per zone. But if you are fine with 
speed, memory and CPU consumption on server side, there is no issue why 
dnsrecord-find shouldn't be used.


Martin


On 13.12.2016 17:47, Mike Driscoll wrote:

Thanks Martin.  That is the cause...

$ ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit
Enter LDAP Password:
nsslapd-sizelimit: 2000

This command results in a similar problem that only 100 of 270 record names 
were returned.
$  ipa dnsrecord-find mydomain.com qa

If I specify these limits, I get all 270 records as expected.
$  ipa dnsrecord-find mydomain.com qa --sizelimit=1 --timelimit=20

I have the impression this default size limit meets most needs.  Is my approach 
wrong when wanting to dump the entire DNS list of records via ipa 
dnsrecord-find?

Mike



On Dec 13, 2016, at 08:17, Martin Basti <mba...@redhat.com> wrote:

Tomas already replied to you, copying here as archives are currently offline to 
prevent spam

"""

Hi,

you seem to be hitting the size limit on LDAP side. To verify, check

ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit

If you really need to increase this size limit, you will have to modify the 
nsslapd-sizelimit in cn=config.

"""

Martin


On 13.12.2016 17:06, Mike Driscoll wrote:

Any thoughts about this sizelimit bug?

Mike




On Nov 28, 2016, at 14:44, Mike Driscoll <mike.drisc...@oracle.com> wrote:

I'm running:
# rpm -qa | grep ipa-server
ipa-server-4.4.0-12.0.1.el7.x86_64
ipa-server-dns-4.4.0-12.0.1.el7.noarch
ipa-server-common-4.4.0-12.0.1.el7.noarch

Searching DNS for all hostnames containing "qa" times out in the GUI.  Setting 
aside the option to change server defaults, this cli command isn't giving me the content 
I need:

# ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
ipa: WARNING: Search result has been truncated: Configured size limit exceeded

It seems like the sizelimit parameter greater than two thousand is being 
ignored:

# ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
...
---
Number of entries returned 1900
---

# ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
...
---
Number of entries returned 2000
---

Any suggestions?

Mike


--
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] DNS search timeouts and incomplete results

[Martin Basti]

Tomas already replied to you, copying here as archives are currently 
offline to prevent spam


"""

Hi,

you seem to be hitting the size limit on LDAP side. To verify, check

ldapsearch -D 'cn=directory manager' -W -b cn=config cn=config | grep 
nsslapd-sizelimit


If you really need to increase this size limit, you will have to modify 
the nsslapd-sizelimit in cn=config.


"""

Martin


On 13.12.2016 17:06, Mike Driscoll wrote:

Any thoughts about this sizelimit bug?

Mike




On Nov 28, 2016, at 14:44, Mike Driscoll  wrote:

I'm running:
# rpm -qa | grep ipa-server
ipa-server-4.4.0-12.0.1.el7.x86_64
ipa-server-dns-4.4.0-12.0.1.el7.noarch
ipa-server-common-4.4.0-12.0.1.el7.noarch

Searching DNS for all hostnames containing "qa" times out in the GUI.  Setting 
aside the option to change server defaults, this cli command isn't giving me the content 
I need:

# ipa dnsrecord-find mydomain.com --sizelimit=1 --timelimit=20 | grep qa
ipa: WARNING: Search result has been truncated: Configured size limit exceeded

It seems like the sizelimit parameter greater than two thousand is being 
ignored:

# ipa dnsrecord-find mydomain.com --sizelimit=1900 --timelimit=20
...
---
Number of entries returned 1900
---

# ipa dnsrecord-find mydomain.com --sizelimit=2100 --timelimit=20
...
---
Number of entries returned 2000
---

Any suggestions?

Mike




--
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] Removing DNS component

[Martin Basti]

On 08.12.2016 12:01, Brian Candler wrote:
FreeIPA (4.2.0) was installed with the DNS component enabled, but I 
want to pull this out. Is it possible to remove it and clean up the 
records which were already there?


e.g. is it sufficient just to delete everything under 
cn=dns,dc=example,dc=com ?  I notice there are bunch of permissions 
entries in other parts of the tree which reference these with 
ipaPermTarget, do they have to go too?


Or would I have to re-install from scratch?

Thanks,

Brian.


Hello,


I suggest to keep DNS tree there and all permissions, just remove all 
zones using IPA API and disable DNS service and dnssyncd service in 
LDAP, because removing DNS completely is unsupported and untested


dn: cn=DNS,cn=vm-028.ipa.test,cn=masters,cn=ipa,cn=etc,$SUFFIX
objectClass: ipaConfigObject
objectClass: nsContainer
objectClass: top
ipaConfigString: startOrder 30
ipaConfigString: enabledService <--- remove this
cn: DNS


dn: cn=DNSKeySync,cn=vm-028.ipa.test,cn=masters,cn=ipa,$SUFFIX
objectClass: nsContainer
objectClass: top
ipaConfigString: dnssecVersion 1
ipaConfigString: startOrder 110
ipaConfigString: enabledService < remove this
cn: DNSKeySync

It will keep ipa dns* command working but without any effect



in case you *really* want to remove DNS completely, disable services ^, 
and revert everything added by 
https://github.com/freeipa/freeipa/blob/master/install/share/dns.ldif 
and https://github.com/freeipa/freeipa/blob/master/install/share/dnssec.ldif


But unsupported, nobody knows what may happen.

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

[Freeipa-users] FreeIPA server docker images have been migrated to freeipa organization

[Martin Basti]

Hello,

I would like to announce that FreeIPA server docker images have been 
migrated to freeipa organization:


* images: https://hub.docker.com/r/freeipa/freeipa-server/

* sources: https://github.com/freeipa/freeipa-container

* additional info: http://www.freeipa.org/page/Docker


Happy hacking,

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] Let's Encrypt Install: Made a bit of install progress, next error

[Martin Basti]

Please make sure you use `hostnamectl set-hostname FQDN` to set all 
hostnames on system (static, tentaive, current )


Martin

On 07.12.2016 16:52, Joseph Flynn wrote:
Damn, I thought I already fixed that but didn't. Hold while I 
rerun...   I bet that was it.


On Wed, Dec 7, 2016 at 10:50 AM, Martin Basti <mba...@redhat.com 
<mailto:mba...@redhat.com>> wrote:


What does `hostname` command return?


On 07.12.2016 16:37, Joseph Flynn wrote:

Sorry, I wasn't clear in my earlier subject line.  This is
related to the Lets Encrypt installation.

I tried to pull some more relevant items from the log below.  I
don't actually see all of the elements of my FQDN
(ipa-a.kkgpitt.org <http://ipa-a.kkgpitt.org>) only references to
the host (ipa-a) in the log, but am not sure what a good log
should include.

Thanks for any assistance,
Joe


On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn <jjflyn...@gmail.com
<mailto:jjflyn...@gmail.com>> wrote:

Volunteers,

I moved over to a Fedora VM which was way more difficult than
it should be.  All kinds of problems with Guest Additions and
I ended up having to run server mode with no GUI.  Now I run
an Ubuntu VM from which I ssh into my Fedora VM.  Anyway...

The install made it a further step than before.  I get a
quick blue screen pop up at the end then an error saying:
Inline image 1

An unexpected error occurred:
The request message was malformed :: DNS name does not
have enough labels
Please see the logfiles in /var/log/letsencrypt for more
details.


When I run the cert checker util I get this
https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org
<https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org>


Full log below.

Any suggestions?  Is it not pulling my proper hostname?

Thanks,
Joe





[jjflynn22@ipa-a ~]$ cat /etc/hosts
192.168.1.211ipa-a.kkgpitt.org <http://ipa-a.kkgpitt.org> ipa-a
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6




[jjflynn22@ipa-a ~]$ sudo cat
/var/log/letsencrypt/letsencrypt.log
[sudo] password for jjflynn22:
2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level
set at 20
2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
/var/log/letsencrypt/letsencrypt.log
2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments:
['--standalone', '--csr', '/root/ipa-le/httpd-csr.der',
'--email', 'xx...@gmail.com <mailto:xx...@gmail.com>',
'--agree-tos']
2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered
plugins:

PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-12-06
20:57:43,995:DEBUG:certbot.plugins.selection:Requested
authenticator standalone and installer None
2016-12-06
20:57:44,019:DEBUG:certbot.plugins.selection:Single candidate
plugin: * standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone =
certbot.plugins.standalone:Authenticator
Initialized: http://certbot.plugins.standalone.Au>thenticator object at
0x7fc3dc6fccd0>
Prep: True
2016-12-06
20:57:44,019:DEBUG:certbot.plugins.selection:Selected
authenticator http://certbot.plugins.standalone.Au>thenticator object at
0x7fc3dc6fccd0> and installer None
2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:
<Account(7446b15565eb5a2fc5850f3ad97dc6dc)>
2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
https://acme-v01.api.letsencrypt.org/directory
<https://acme-v01.api.letsencrypt.org/directory>. args: (),
kwargs: {}
2016-12-06
20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
new HTTPS connection (1): acme-v01.api.letsencrypt.org
<http://acme-v01.api.letsencrypt.org>
2016-12-06 20:57:44,500:DEBUG:requests.pa
<http://requests.pa>ckages.urllib3.connectionpool:"GET
/directory HTTP/1.1" 200 280
2016-12-06 20:57:44,506:DEBUG:root:Received .
Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec
2016 20:57:46 GMT', 'Boulder-Request-Id':
'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
'Strict-Transport-Security': 'max-age=604800', 'Server':
'nginx', '

Re: [Freeipa-users] Let's Encrypt Install: Made a bit of install progress, next error

[Martin Basti]

What does `hostname` command return?


On 07.12.2016 16:37, Joseph Flynn wrote:
Sorry, I wasn't clear in my earlier subject line.  This is related to 
the Lets Encrypt installation.


I tried to pull some more relevant items from the log below.  I don't 
actually see all of the elements of my FQDN (ipa-a.kkgpitt.org 
) only references to the host (ipa-a) in the 
log, but am not sure what a good log should include.


Thanks for any assistance,
Joe


On Tue, Dec 6, 2016 at 4:15 PM, Joseph Flynn > wrote:


Volunteers,

I moved over to a Fedora VM which was way more difficult than it
should be.  All kinds of problems with Guest Additions and I ended
up having to run server mode with no GUI.  Now I run an Ubuntu VM
from which I ssh into my Fedora VM. Anyway...

The install made it a further step than before.  I get a quick
blue screen pop up at the end then an error saying:
Inline image 1

An unexpected error occurred:
The request message was malformed :: DNS name does not have
enough labels
Please see the logfiles in /var/log/letsencrypt for more details.


When I run the cert checker util I get this
https://www.sslshopper.com/ssl-checker.html#hostname=ipa-a.kkgpitt.org



Full log below.

Any suggestions?  Is it not pulling my proper hostname?

Thanks,
Joe





[jjflynn22@ipa-a ~]$ cat /etc/hosts
192.168.1.211ipa-a.kkgpitt.org  ipa-a
127.0.0.1   localhost localhost.localdomain localhost4
localhost4.localdomain4
::1 localhost localhost.localdomain localhost6
localhost6.localdomain6




[jjflynn22@ipa-a ~]$ sudo cat /var/log/letsencrypt/letsencrypt.log
[sudo] password for jjflynn22:
2016-12-06 20:57:43,982:DEBUG:certbot.main:Root logging level set
at 20
2016-12-06 20:57:43,983:INFO:certbot.main:Saving debug log to
/var/log/letsencrypt/letsencrypt.log
2016-12-06 20:57:43,991:DEBUG:certbot.main:certbot version: 0.9.3
2016-12-06 20:57:43,991:DEBUG:certbot.main:Arguments:
['--standalone', '--csr', '/root/ipa-le/httpd-csr.der', '--email',
'xx...@gmail.com ', '--agree-tos']
2016-12-06 20:57:43,992:DEBUG:certbot.main:Discovered plugins:

PluginsRegistry(PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2016-12-06 20:57:43,995:DEBUG:certbot.plugins.selection:Requested
authenticator standalone and installer None
2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Single
candidate plugin: * standalone
Description: Spin up a temporary webserver
Interfaces: IAuthenticator, IPlugin
Entry point: standalone = certbot.plugins.standalone:Authenticator
Initialized: 
Prep: True
2016-12-06 20:57:44,019:DEBUG:certbot.plugins.selection:Selected
authenticator  and installer None
2016-12-06 20:57:44,115:DEBUG:certbot.main:Picked account:

2016-12-06 20:57:44,116:DEBUG:root:Sending GET request to
https://acme-v01.api.letsencrypt.org/directory
. args: (), kwargs: {}
2016-12-06
20:57:44,119:INFO:requests.packages.urllib3.connectionpool:Starting
new HTTPS connection (1): acme-v01.api.letsencrypt.org

2016-12-06
20:57:44,500:DEBUG:requests.packages.urllib3.connectionpool:"GET
/directory HTTP/1.1" 200 280
2016-12-06 20:57:44,506:DEBUG:root:Received .
Headers: {'Content-Length': '280', 'Expires': 'Tue, 06 Dec 2016
20:57:46 GMT', 'Boulder-Request-Id':
'mqxztXHk-k5DDBqftS_2vmB0sWVWVjS1twToXbIOdL0',
'Strict-Transport-Security': 'max-age=604800', 'Server': 'nginx',
'Connection': 'keep-alive', 'Pragma': 'no-cache', 'Cache-Control':
'max-age=0, no-cache, no-store', 'Date': 'Tue, 06 Dec 2016
20:57:46 GMT', 'X-Frame-Options': 'DENY', 'Content-Type':
'application/json', 'Replay-Nonce':
'sz4mf6DlGO-Iw1q8bOlAlisD3CKZlCZUA9JzmN3dcDk'}. Content: '{\n 
"new-authz": "https://acme-v01.api.letsencrypt.org/acme/new-authz

",\n
"new-cert": "https://acme-v01.api.letsencrypt.org/acme/new-cert
",\n
"new-reg": "https://acme-v01.api.letsencrypt.org/acme/new-reg
",\n
"revoke-cert":
"https://acme-v01.api.letsencrypt.org/acme/revoke-cert
"\n}'
2016-12-06 20:57:44,506:DEBUG:acme.client:Received response
 (headers: {'Content-Length': '280', 'Expires':
'Tue, 06 Dec 2016 20:57:46 GMT', 'Boulder-Request-Id':

Re: [Freeipa-users] What should the --hostname option do?

[Martin Basti]

On 07.12.2016 15:21, Rob Crittenden wrote:

Martin Basti wrote:


On 07.12.2016 08:48, List dedicated to discussions about use,
configuration and deployment of the IPA server. wrote:

Hello,

the --hostname option to the installer currently modifies the hostname
of the machine. In some environments, namely in unprivileged
containers, that operation is not denied. In some cases, it is
possible to change the FQDN of the container from outside, for example
with docker run's -h option. However, in some environments, namely in
OpenShift, there is not such possibility.

I have found out that disabling the change by turning /bin/hostnamectl
and /usr/bin/domainname makes ipa-server-install pass while the server
gets configured with the hostname specified as the parameter to
--hostname option so it does not seem to be essential for the FQDN to
change. Of course, some operations might no longer work, like ssh to
the FreeIPA machine as sshd would need to be set with
GSSAPIStrictAcceptorCheck no.

I wonder if either change of the --hostname semantics, or some new
option would be useful, to specify the hostname to be used by the
FreeIPA software while not touching the configuration of the hostname
for the machine.


I agree that --hostname options should not touch system's hostname, I
don't see reason why application installer should change system hostname.

It was done for sanity because a staggering number of users it seems
don't properly set their hostname.


Then we should have checks and prevent installation, but this needs 
proper design and must cover containers, AWS, etc. to count with various 
scenarios.





I'd start with deprecating current behavior of this option in next release

IMHO it is a pretty significant change of behavior.

True, so as mentioned later, rather just deprecate this option.




As you mentioned we need find what cases can be broken when we will use
different local and external hostname, but anyway we have do this for
containers.

Agreed. Something needs to happen, I'm just not convinced it should
happen in --hostname. I generally oppose new options but one might be
warranted in this case to handle things.


Maybe --external-hostname or so, noted, we will cover it in design.



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] What should the --hostname option do?

[Martin Basti]

On 07.12.2016 08:48, List dedicated to discussions about use, 
configuration and deployment of the IPA server. wrote:

Hello,

the --hostname option to the installer currently modifies the hostname
of the machine. In some environments, namely in unprivileged
containers, that operation is not denied. In some cases, it is
possible to change the FQDN of the container from outside, for example
with docker run's -h option. However, in some environments, namely in
OpenShift, there is not such possibility.

I have found out that disabling the change by turning /bin/hostnamectl
and /usr/bin/domainname makes ipa-server-install pass while the server
gets configured with the hostname specified as the parameter to
--hostname option so it does not seem to be essential for the FQDN to
change. Of course, some operations might no longer work, like ssh to
the FreeIPA machine as sshd would need to be set with
GSSAPIStrictAcceptorCheck no.

I wonder if either change of the --hostname semantics, or some new
option would be useful, to specify the hostname to be used by the
FreeIPA software while not touching the configuration of the hostname
for the machine.



I agree that --hostname options should not touch system's hostname, I 
don't see reason why application installer should change system hostname.


I'd start with deprecating current behavior of this option in next release

As you mentioned we need find what cases can be broken when we will use 
different local and external hostname, but anyway we have do this for 
containers.


Martin^2

--
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] SPAM, please ban this user

[Martin Basti]

On 28.11.2016 08:10, Denis Müller wrote:

kimirachel1...@tmtis.com 

spamming all the time.
Please help.




It is not registered user, it is spambot that is mining public archives, 
it is not sent from RH servers, we can't help here, sorry.
-- 
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] ipalib authentication

[Martin Basti]

On 24.11.2016 16:57, Alexander Bokovoy wrote:

On to, 24 marras 2016, Adam Bishop wrote:

I'm writing a bit of code using ipalib directly, I'm a little stuck on
authentication though.

It works fine if grab a Kerberos ticket with kinit then run the code
interactively, but I'd like to run this as a daemon which makes
maintaining a ticket tricky.

What other options are there for authenticating to the API, avoiding
calling external tools like curl or kinit?

Python API right now only accepts Kerberos ticket.

I think we have a ticket to improve on this but right now your options
are limited.


Might be possible to use python-gssapi and kinit_keytab function instead 
of kinit command?


Martin^2

--
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 forwarded domain name.

[Martin Basti]

On 23.11.2016 03:48, TomK wrote:

On 11/22/2016 10:22 AM, Martin Basti wrote:



On 22.11.2016 13:57, TomK wrote:

On 11/22/2016 2:59 AM, Martin Basti wrote:

Hey,


On 22.11.2016 06:33, TomK wrote:

Hey Guy's,

I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 
over to

my dual Free IPA server.  The Free IPA servers are authoritative for
this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
and forwards dom.abc.xyz.
Do you have configured proper zone delegation for subdomain 
dom.abc.xyz?

Proper NS and glue records
http://www.zytrax.com/books/dns/ch9/delegate.html



I cannot ping dom.abc.xyz.  Everything else, including client
registrations, work fine.  If Free IPA is authoritative on
dom.abc.xyz, should it not create DNS entries so the sub domain 
can be

pinged as well?


What do you mean by "ping"?



/etc/resolv.conf also get's regenerated on reboot on the IPA Servers
and wanted to ask if you can point me to some materials online to
determine where can I permanently adjust the search to add 
dom.abc.xyz

to the already present abc.xyz .  I wasn't able to locate what I
needed in my searches.

I'm using the latest v4.


It depends on what are you using, probably you have NetworkManager 
there

that is editing /etc/resolv.conf

https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ 





Martin



I Uninstalled NetworkManager.  Still changes.
ping dom.abc.com results in "ping: unknown host"

I'll have a look at the first link, ty.



ping (ICMP protocol) and DNS system are different things, do you have
hostname dom.abc.com with A record or it is a zone?

with ping command hostname "dom.abc.com" is resolved to IP address
first, do you have A record set for dom.abc.com in zone apex or what are
you trying to achieve with ping command?

for testing DNS try to use commands: dig, host, nslookup

Martin



Apologize for the long reply but it should give some background on 
what it is that I'm doing.


1) dom.abc.com is a zone.  There is no A record for dom.abc.com in 
FreeIPA (Confirmed by Petr).  I get the point Petr Spacek pointed out 
in his comment as well.  What should it really point too? ( I kind of 
answer this question below so please read on. )  Where I'm getting 
this from is that in Windows Server 2012 abc.com returns the IP of any 
of the participating AD / DNS servers within the cluster (The two 
Windows Server 2012 are a combined clustered AD + DNS servers.).  
Being able to resolve abc.xyz is handy.  During a lookup, I can get a 
list of all the IP's associated with that domain which would indicate 
all the DNS + AD servers online under that domain or serving that domain:



# nslookup abc.xyz
Server: 192.168.0.3
Address:192.168.0.3#53

Name:   abc.xyz
Address: 192.168.0.3
Name:   abc.xyz
Address: 192.168.0.1
Name:   abc.xyz
Address: 192.168.0.2
#

Again, where this is handy is when configuring sssd.conf for example 
or other apps for that matter.  I can just point the app to 
authenticate against the domain and I have my redundancy solved.  
Windows Server 2012 does it, but FreeIPA didn't, so I threw the 
question out there.


IPA uses SRV records heavily, all IPA related services have SRV records, 
SSSD uses SRV records of IPA, client should use SRV record to connect to 
the right service (or URI record - will be in next IPA). SRV records 
work for IPA locations mechanism, we cannot achieve this with pure A 
records.




Delegation from this Windows DNS works as expected.  Any lookup from 
dom.abc.xyz is forwarded too and handled by FreeIPA servers. Tested 
this out. No issue with this.


I did see earlier that there is no A record for dom.abc.xyz in 
FreeIPA. My reasons for asking if there was an IP on the subdomain in 
FreeIPA were above but the missing IP on the subdomain isn't a major 
issue for me.  Things are working without dom.abc.xyz resolving to an 
IP.  What I was hoping for is to have a VIP for the IPA servers and 
one for the Windows Server 2012 DNS Cluster in /etc/resolv.conf.  (I 
have the VIP for the windows server).  One forwarding to the other for 
a given domain.  This is all for testing a) redundancy, b) forwarding, 
a) authentication .


IE:

# cat /etc/resolv.conf
search nix.mds.xyz mds.xyz
nameserver 192.168.0.3< Win Cluster DNS VIP
nameserver 192.168.0.4< IPA Cluster DNS VIP

* Just what I want to achieve above.  VIP 192.168.0.4 doesn't exist on 
my cluster yet.  I'm looking to integrate ucarp with the above IPA 
servers.



2) More to the topic of my second question however, is that 
/etc/resolv.conf, on the IPA servers themselves, get's rewritten on 
restart.  Would like to know by what if I already uninstalled 
NetworkManager?  When I configured the FreeIPA server, I used:


ipa-server-install --setup-dns --forwarder=192.168.0.3 -p "Hush!" -a 
"Hush!" -r DOM.ABC.XYZ -n 

Re: [Freeipa-users] Ping forwarded domain name.

[Martin Basti]

On 22.11.2016 13:57, TomK wrote:

On 11/22/2016 2:59 AM, Martin Basti wrote:

Hey,


On 22.11.2016 06:33, TomK wrote:

Hey Guy's,

I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to
my dual Free IPA server.  The Free IPA servers are authoritative for
this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz
and forwards dom.abc.xyz.

Do you have configured proper zone delegation for subdomain dom.abc.xyz?
Proper NS and glue records
http://www.zytrax.com/books/dns/ch9/delegate.html



I cannot ping dom.abc.xyz.  Everything else, including client
registrations, work fine.  If Free IPA is authoritative  on
dom.abc.xyz, should it not create DNS entries so the sub domain can be
pinged as well?


What do you mean by "ping"?



/etc/resolv.conf also get's regenerated on reboot on the IPA Servers
and wanted to ask if you can point me to some materials online to
determine where can I permanently adjust the search to add dom.abc.xyz
to the already present abc.xyz .  I wasn't able to locate what I
needed in my searches.

I'm using the latest v4.


It depends on what are you using, probably you have NetworkManager there
that is editing /etc/resolv.conf

https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/ 




Martin



I Uninstalled NetworkManager.  Still changes.
ping dom.abc.com results in "ping: unknown host"

I'll have a look at the first link, ty.



ping (ICMP protocol) and DNS system are different things, do you have 
hostname dom.abc.com with A record or it is a zone?


with ping command hostname "dom.abc.com" is resolved to IP address 
first, do you have A record set for dom.abc.com in zone apex or what are 
you trying to achieve with ping command?


for testing DNS try to use commands: dig, host, nslookup

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] Ping forwarded domain name.

[Martin Basti]

Hey,


On 22.11.2016 06:33, TomK wrote:

Hey Guy's,

I'm forwarding a domain dom.abc.xyz from a Windows Server 2012 over to 
my dual Free IPA server.  The Free IPA servers are authoritative for 
this subdomain.  The Windows Server 2012 DNS is resolves on abc.xyz 
and forwards dom.abc.xyz.
Do you have configured proper zone delegation for subdomain dom.abc.xyz? 
Proper NS and glue records http://www.zytrax.com/books/dns/ch9/delegate.html




I cannot ping dom.abc.xyz.  Everything else, including client 
registrations, work fine.  If Free IPA is authoritative  on 
dom.abc.xyz, should it not create DNS entries so the sub domain can be 
pinged as well?


What do you mean by "ping"?



/etc/resolv.conf also get's regenerated on reboot on the IPA Servers 
and wanted to ask if you can point me to some materials online to 
determine where can I permanently adjust the search to add dom.abc.xyz 
to the already present abc.xyz .  I wasn't able to locate what I 
needed in my searches.


I'm using the latest v4.


It depends on what are you using, probably you have NetworkManager there 
that is editing /etc/resolv.conf


https://ask.fedoraproject.org/en/question/67752/how-do-i-add-a-search-domain-using-networkmanager/

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] Disabling Anonymous Binds (LDAP)

[Martin Basti]

So annonymous bind should be disabled


can you try ldapsearch without any login information?


On 16.11.2016 19:01, dan.finkelst...@high5games.com wrote:


I'm on FreeIPA 4.x

id:image001.jpg@01D1C26F.0E28FA60 <http://www.high5games.com/>

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com <mailto:dan.finkelst...@h5g.com>_ | 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com <http://www.high5games.com/>

Play High 5 Casino <https://apps.facebook.com/highfivecasino/> and 
Shake the Sky <https://apps.facebook.com/shakethesky/>


Follow us on: Facebook <http://www.facebook.com/high5games>, Twitter 
<https://twitter.com/High5Games>, YouTube 
<http://www.youtube.com/High5Games>, Linkedin 
<http://www.linkedin.com/company/1072533?trk=tyah>


//

/This message and any attachments may contain confidential or 
privileged information and are only for the use of the intended 
recipient of this message. If you are not the intended recipient, 
please notify the sender by return email, and delete or destroy this 
and all copies of this message and all attachments. Any unauthorized 
disclosure, use, distribution, or reproduction of this message or any 
attachments is prohibited and may be unlawful./


*From: *Martin Basti <mba...@redhat.com>
*Date: *Wednesday, November 16, 2016 at 12:47
*To: *Dan Finkelstein <dan.finkelst...@high5games.com>, 
"freeipa-users@redhat.com" <freeipa-users@redhat.com>

*Subject: *Re: [Freeipa-users] Disabling Anonymous Binds (LDAP)

On 16.11.2016 17:46, dan.finkelst...@high5games.com 
<mailto:dan.finkelst...@high5games.com> wrote:


I've seen some discussion in the (distant) past about disabling
anonymous binds to the LDAP component of IPA, and I'm wondering if
there's a preferred method to do it. Further, are there any known
problems with disabling anonymous binds when using FreeIPA? The
only modern documentation I can find is here:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html,
and I'm curious if FreeIPA has a different way.

Thanks,

Dan

<http://www.high5games.com/>

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com <mailto:dan.finkelst...@h5g.com>_ |
212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com <http://www.high5games.com/>

Play High 5 Casino <https://apps.facebook.com/highfivecasino/> and
Shake the Sky <https://apps.facebook.com/shakethesky/>

Follow us on: Facebook <http://www.facebook.com/high5games>,
Twitter <https://twitter.com/High5Games>, YouTube
<http://www.youtube.com/High5Games>, Linkedin
<http://www.linkedin.com/company/1072533?trk=tyah>

//

/This message and any attachments may contain confidential or
privileged information and are only for the use of the intended
recipient of this message. If you are not the intended recipient,
please notify the sender by return email, and delete or destroy
this and all copies of this message and all attachments. Any
unauthorized disclosure, use, distribution, or reproduction of
this message or any attachments is prohibited and may be unlawful./



It depends on your FreeIPA version, 3.x is explained in link you 
posted, 4.x has a permission for this.


Sa what is your freeIPA version?

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] Disabling Anonymous Binds (LDAP)

[Martin Basti]

On 16.11.2016 18:47, Martin Basti wrote:




On 16.11.2016 17:46, dan.finkelst...@high5games.com wrote:


I've seen some discussion in the (distant) past about disabling 
anonymous binds to the LDAP component of IPA, and I'm wondering if 
there's a preferred method to do it. Further, are there any known 
problems with disabling anonymous binds when using FreeIPA? The only 
modern documentation I can find is here: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, 
and I'm curious if FreeIPA has a different way.


Thanks,

Dan

id:image001.jpg@01D1C26F.0E28FA60 <http://www.high5games.com/>

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com <mailto:dan.finkelst...@h5g.com>_ | 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com <http://www.high5games.com/>

Play High 5 Casino <https://apps.facebook.com/highfivecasino/> and 
Shake the Sky <https://apps.facebook.com/shakethesky/>


Follow us on: Facebook <http://www.facebook.com/high5games>, Twitter 
<https://twitter.com/High5Games>, YouTube 
<http://www.youtube.com/High5Games>, Linkedin 
<http://www.linkedin.com/company/1072533?trk=tyah>


//

/This message and any attachments may contain confidential or 
privileged information and are only for the use of the intended 
recipient of this message. If you are not the intended recipient, 
please notify the sender by return email, and delete or destroy this 
and all copies of this message and all attachments. Any unauthorized 
disclosure, use, distribution, or reproduction of this message or any 
attachments is prohibited and may be unlawful./




It depends on your FreeIPA version, 3.x is explained in link you 
posted, 4.x has a permission for this.


Sa what is your freeIPA version?

Martin



And I forgot to add, those should be disabled by default in IPA 4.x
-- 
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] Disabling Anonymous Binds (LDAP)

[Martin Basti]

On 16.11.2016 17:46, dan.finkelst...@high5games.com wrote:


I've seen some discussion in the (distant) past about disabling 
anonymous binds to the LDAP component of IPA, and I'm wondering if 
there's a preferred method to do it. Further, are there any known 
problems with disabling anonymous binds when using FreeIPA? The only 
modern documentation I can find is here: 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/disabling-anon-binds.html, 
and I'm curious if FreeIPA has a different way.


Thanks,

Dan

id:image001.jpg@01D1C26F.0E28FA60 

*Daniel Alex Finkelstein*| Lead Dev Ops Engineer

_dan.finkelst...@h5g.com _ | 212.604.3447

One World Trade Center, New York, NY 10007

www.high5games.com 

Play High 5 Casino  and 
Shake the Sky 


Follow us on: Facebook , Twitter 
, YouTube 
, Linkedin 



//

/This message and any attachments may contain confidential or 
privileged information and are only for the use of the intended 
recipient of this message. If you are not the intended recipient, 
please notify the sender by return email, and delete or destroy this 
and all copies of this message and all attachments. Any unauthorized 
disclosure, use, distribution, or reproduction of this message or any 
attachments is prohibited and may be unlawful./




It depends on your FreeIPA version, 3.x is explained in link you posted, 
4.x has a permission for this.


Sa what is your freeIPA version?

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] anyone else getting porn spam pretending to be replies to freeipa-users threads?

[Martin Basti]

On 15.11.2016 17:32, Chris Dagdigian wrote:



Got a porn spam today that had a subject header of:


Re: [Freeipa-users] URL is changing on the browser


Have to admit that got through my spam filter and got me to open the 
email.


It's clear that it was not a list message; looks like something may be 
mining the public list archives to pull email addresses and plausible 
sounding subject lines.


Mildly interested if anyone else got an email like this?

-Chris


 We are receiving those emails as well (different subjects, domains, 
but the same content)


--
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] Differences between "ipa-replica-manage connect --winsync..." and ipa-adtrust-install ... ipa trust-add...

[Martin Basti]

On 15.11.2016 15:33, James Harrison wrote:

Hello,
Are there any differences between establishing a Replication Agreement 
using "ipa-replica-manage connect --winsync"  and establishing an AD 
Trust Relationship using the commands ipa-adtrust-install ...  ipa 
trust-add ...


Are they used together or are they different methods to accomplish the 
same goal: to get AD user accounts? Which one is preferred?


Best regards,
James Harrison




Hello, you may find answers here
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/introduction.html

AD Trust method is preferred

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