Re: [Freeipa-users] Server Ports
On 3.4.2014 07:55, Justin Brown wrote: I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). http://www.freeipa.org/page/Documentation is the ultimate source of documentation. Latest documentation build is on http://www.freeipa.org/docs/master/html-desktop/index.html I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except dogtag, which I made myself and is defined at the end. ipa-replica-conncheck utility should tell you what is missing. On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Patches are welcome :-) -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Server Ports
Petr, I'll try another replica for testing tomorrow, and unfortunately the logs were purged when I reinstalled. The error message was not helpful and said something along the lines of CA installation failed, but did not list any reason. I'll get you the exact message tomorrow. I'll also try some more network tests as I have all of the ports that you listed plus some additional Dogtag ports, which I've come to understand are now proxied through 7389. Patches are welcome :-) Yes, you've got me. ;) I'll review the Firewalld packaging in more detail and try to come up with a workable solution. It's not currently possible to do meta-services in firewalld, and I'm sure the FreeIPA developers don't want a hard dependency on firewalld via a hypothetical freeipa-server-firewalld dependency. I'm sure some solution is possible -- maybe even just in the documentation. Thanks, Justin On Thu, Apr 3, 2014 at 2:25 AM, Petr Spacek pspa...@redhat.com wrote: On 3.4.2014 07:55, Justin Brown wrote: I'm having some trouble determining which ports my servers need open to communicate and what ports client servers and users will need. The last documentation that I was able to find was included in Fedora 15 (http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/installing-ipa.html). http://www.freeipa.org/page/Documentation is the ultimate source of documentation. Latest documentation build is on http://www.freeipa.org/docs/master/html-desktop/index.html I opened those ports with firewalld, but I encountered errors when joining my replica server. (I retried the replica install with firewalld, and it succeeded, so it's clearly a problem with the firewall settings.) I'm joining the wave of the future, so please excuse the firewalld XML, but it should be pretty obvsious. All of the services are built into firewalld, except dogtag, which I made myself and is defined at the end. ipa-replica-conncheck utility should tell you what is missing. On a side note, it would be nice if the firewalld packagers included a freeipa-server service (nudge nudge). Patches are welcome :-) -- Petr^2 Spacek ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Server Ports
On 04/03/2014 09:46 AM, Justin Brown wrote: Petr, I'll try another replica for testing tomorrow, and unfortunately the logs were purged when I reinstalled. The error message was not helpful and said something along the lines of CA installation failed, but did not list any reason. I'll get you the exact message tomorrow. I'll also try some more network tests as I have all of the ports that you listed plus some additional Dogtag ports, which I've come to understand are now proxied through 7389. Patches are welcome :-) Yes, you've got me. ;) I'll review the Firewalld packaging in more detail and try to come up with a workable solution. It's not currently possible to do meta-services in firewalld, and I'm sure the FreeIPA developers don't want a hard dependency on firewalld via a hypothetical freeipa-server-firewalld dependency. I'm sure some solution is possible -- maybe even just in the documentation. Thanks, Justin Hi Justin, Petr is right, patches and contributions are extremely welcome :-) Let me just pass the initial information in case you'd want to accept this challenge: How to contribute: http://www.freeipa.org/page/Contribute/Code Trac ticket with related information and links to Bugzillas: https://fedorahosted.org/freeipa/ticket/2110 Actually I do not think that freeipa-server-firewalld or similar is that bad idea. We already thought of shipping our own firewalld file(s) and such subpackage may be a way to go. This is something that can be discussed on freeipa-devel list. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory
Yes, I did that, here is the log [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local@UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local@UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] ipa: INFO: admin@UNIX: ping(): SUCCESS [Thu Apr 03 13:21:55 2014] [error] ipa: INFO: admin@UNIX: trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'admsredmo01', realm_passwd=u'', range_size=20, all=False, raw=False, version=u'2.49'): NotFound -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Thursday, April 03, 2014 12:12 PM To: Redmond, Stacy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory On Thu, 03 Apr 2014, Redmond, Stacy wrote: I have this same exact issue. I have not only verified that DNS is functioning properly, I have also added the AD server to the local hosts file as is the reported fix for this issue and it still persists. add log level = 100 to [global] section in /usr/share/ipa/smb.conf.empty and try 'ipa trust-add' again. You'll get debug output in httpd's error_log. I'd like to see level 100 logs, they give a bit more details in case of SMB Python bindings. -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] DDNS with DHCPD and IPA
On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote:
That would be my preference, would then work same as bind/dhcpd before
switching to ipa. I just dont know how to do it correctly.
This assumes dhcp and named are on the same system.
For an unrelated project I wrote some docs here:
http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-network
And the example config files referenced are:
https://github.com/micolous/tollgate/tree/master/docs/example/fedora
The important parts are:
rndc-confgen -a -r keyboard -b 256
chown named:named /etc/rndc.key
In named.conf add after the options section:
include /etc/rndc.key;
In the zone (In ipa you will need to add this permission)
grant rndc-key wildcard * ANY;
Then in dhcpd:
include /etc/rndc.key;
And to the dhcpd range:
zone dhcp.example.lan. {
primary 127.0.0.1;
key rndc-key;
}
zone 0.4.10.in-addr.arpa. {
primary 127.0.0.1;
key rndc-key;
}
This should coexist peacefully with freeipa, but try to make sure your
DDNS updated zone is say dhcp.example.com rather than a zone you care
about. Consider you have a domain controller called x.example.com, and
you allow DDNS to example.com. If someone set their hostname to x, they
could take over the DNS records for your DC. Better to have a second
zone to prevent this.
--
William Brown will...@firstyear.id.au
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
On 04/03/2014 03:46 PM, Nevada Sanchez wrote: Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 Another strange thing - it looks as if the initial replica init completes successfully. [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - Beginning total update of replica agmt=cn=meToipa2.example.com (ipa2:389). On the replica: [02/Apr/2014:20:50:18 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is going offline; disabling replication [02/Apr/2014:20:50:18 +] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database [02/Apr/2014:20:50:21 +] - import userRoot: Workers finished; cleaning up... [02/Apr/2014:20:50:21 +] - import userRoot: Workers cleaned up. [02/Apr/2014:20:50:21 +] - import userRoot: Indexing complete. Post-processing... [02/Apr/2014:20:50:21 +] - import userRoot: Generating numSubordinates complete. [02/Apr/2014:20:50:21 +] - import userRoot: Flushing caches... [02/Apr/2014:20:50:21 +] - import userRoot: Closing files... [02/Apr/2014:20:50:21 +] - import userRoot: Import complete. Processed 453 entries in 3 seconds. (151.00 entries/sec) [02/Apr/2014:20:50:21 +] NSMMReplicationPlugin - multimaster_be_state_change: replica dc=example,dc=com is coming online; enabling replication On the master, access log: [02/Apr/2014:20:50:17 +] conn=1365 op=15 MOD dn=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config This is the operation that triggers the replica init. Then ipa-replica-install polls for agreement status: [02/Apr/2014:20:50:19 +] conn=1365 op=16 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:19 +] conn=1365 op=16 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:20 +] conn=1365 op=17 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:20 +] conn=1365 op=17 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:21 +] conn=1365 op=18 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:21 +] conn=1365 op=18 RESULT err=0 tag=101 nentries=1 etime=0 [02/Apr/2014:20:50:22 +] conn=1365 op=19 SRCH base=cn=meToipa2.example.com,cn=replica,cn=dc\3Dexample\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=nsds5replicaLastInitStart nsds5replicaUpdateInProgress nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh nsds5replicaLastInitEnd [02/Apr/2014:20:50:22 +] conn=1365 op=19 RESULT err=0 tag=101 nentries=1 etime=1 Something happens here. The replica init is done, according to the replica error log. We don't have the replica access log from around this time to see exactly when the connection was closed, but looking at the ipa code, it would appear that ipa did not see a status of Total update succeeded. Not sure why the master would not have reported that, unless there was some problem getting back the status from the replica. [02/Apr/2014:20:50:22 +] conn=1365 op=20 UNBIND [02/Apr/2014:20:50:22 +] conn=1365 op=20 fd=114 closed - U1 Then ipa-replica-install closes the connection and reports the error. On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson rmegg...@redhat.com mailto:rmegg...@redhat.com wrote: On 04/02/2014 09:22 PM, Nevada Sanchez wrote: Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70 1) Dirsrv is crashing: [02/Apr/2014:20:49:53 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [02/Apr/2014:20:49:54 +] - I'm resizing my cache now...cache was 710029312 and is now 800 [02/Apr/2014:20:49:54 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Apr/2014:20:49:55 +] - slapd started. Listening on All
Re: [Freeipa-users] DDNS with DHCPD and IPA
Awesome, adding the grant line with my key (DDNS_UPDATE) did the trick. This
makes it perform exactly like old config.
Thanks for the help. Someone should put this example in the docs.
-Original Message-
From: freeipa-users-boun...@redhat.com
[mailto:freeipa-users-boun...@redhat.com] On Behalf Of William Brown
Sent: Thursday, April 3, 2014 3:29 PM
To: freeipa-users@redhat.com
Subject: Re: [Freeipa-users] DDNS with DHCPD and IPA
On Thu, 2014-04-03 at 11:02 -0700, Andy Tomlin wrote:
That would be my preference, would then work same as bind/dhcpd before
switching to ipa. I just dont know how to do it correctly.
This assumes dhcp and named are on the same system.
For an unrelated project I wrote some docs here:
http://tollgate.readthedocs.org/en/3.0.1/fedora-deploy.html#core-network
And the example config files referenced are:
https://github.com/micolous/tollgate/tree/master/docs/example/fedora
The important parts are:
rndc-confgen -a -r keyboard -b 256
chown named:named /etc/rndc.key
In named.conf add after the options section:
include /etc/rndc.key;
In the zone (In ipa you will need to add this permission)
grant rndc-key wildcard * ANY;
Then in dhcpd:
include /etc/rndc.key;
And to the dhcpd range:
zone dhcp.example.lan. {
primary 127.0.0.1;
key rndc-key;
}
zone 0.4.10.in-addr.arpa. {
primary 127.0.0.1;
key rndc-key;
}
This should coexist peacefully with freeipa, but try to make sure your DDNS
updated zone is say dhcp.example.com rather than a zone you care about.
Consider you have a domain controller called x.example.com, and you allow
DDNS to example.com. If someone set their hostname to x, they could take
over the DNS records for your DC. Better to have a second zone to prevent
this.
--
William Brown will...@firstyear.id.au
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] IPA Replica Issues (Total update abortedLDAP error: Can't contact LDAP server)
Okay, I updated the gist and extended some of the logs (ipa2-errors does stop at 20:50:21). I'll follow up when I have the debug stuff in place. https://gist.github.com/nevsan/8b6f78d7396963dc5f70 On Thu, Apr 3, 2014 at 10:38 AM, Rich Megginson rmegg...@redhat.com wrote: On 04/02/2014 09:22 PM, Nevada Sanchez wrote: Okay. Updated the gist with the additional logs: https://gist.github.com/nevsan/8b6f78d7396963dc5f70 1) Dirsrv is crashing: [02/Apr/2014:20:49:53 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Db home directory is not set. Possibly nsslapd-directory (optionally nsslapd-db-home-directory) is missing in the config file. [02/Apr/2014:20:49:54 +] - I'm resizing my cache now...cache was 710029312 and is now 800 [02/Apr/2014:20:49:54 +] - 389-Directory/1.3.1.22.a1 B2014.073.1751 starting up [02/Apr/2014:20:49:54 +] - Detected Disorderly Shutdown last time Directory Server was running, recovering database. [02/Apr/2014:20:49:55 +] - slapd started. Listening on All Interfaces port 389 for LDAP requests Please use the instructions at http://port389.org/wiki/FAQ#Debugging_Crashes to get a core dump and stack trace. 2) The first occurrence of the connection error is at [02/Apr/2014:20:52:38 +] but there isn't anything in the consumer error log after [02/Apr/2014:20:50:21 +] and in the consumer access log after [02/Apr/2014:20:50:22 +] On Wed, Apr 2, 2014 at 9:38 PM, Rich Megginson rmegg...@redhat.comwrote: On 04/02/2014 03:01 PM, Nevada Sanchez wrote: Okay, I ran it with debug on. The output is quite large. I'm not sure what the etiquette is for posting large logs, so I threw it on gist here: https://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txthttp://gist.githubusercontent.com/nevsan/8b6f78d7396963dc5f70/raw/b76b3c3acce4f12d292d680f4c1dab39c05888d5/gistfile1.txt Let me know if I should copy it into the thread instead. Ok. Now can you post excerpts from the dirsrv errors log from both the master replica and the replica from around the time of the failure? On Wed, Apr 2, 2014 at 1:49 PM, Rich Megginson rmegg...@redhat.comwrote: On 04/02/2014 11:45 AM, Nevada Sanchez wrote: My apologies. I mistakenly ran the failing ldapsearch from an unpriviliged user (couldn't read slapd-EXAMPLE-COM directory). Running as root, it now works just fine (same result as the one that worked). SSL seems to not be the issue. Also, I haven't change the SSL certs since I first set up the master. I have been doing the replica side things from scratch (even so far as starting with a new machine). For the master side, I have just been re-preparing the replica. I hope I don't have to start from scratch with the master replica. I guess the next step would be to do the ipa-replica-install using -ddd and review the extra debug information that comes out. On Wed, Apr 2, 2014 at 11:45 AM, Rob Crittenden rcrit...@redhat.comwrote: Rich Megginson wrote: On 04/02/2014 09:20 AM, Nevada Sanchez wrote: Okay, we might be on to something: ipa - ipa2 $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa2.example.com http://ipa2.example.com -s base -b 'objectclass=*' vendorVersion dn: vendorVersion: 389-Directory/1.3.1.22.a1 B2014.073.1751 ipa2 - ipa $ LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-EXAMPLE-COM ldapsearch -xLLLZZ -h ipa.example.com http://ipa.example.com -s base -b 'objectclass=*' vendorVersion ldap_start_tls: Connect error (-11) additional info: TLS error -8172:Peer's certificate issuer has been marked as not trusted by the user. The original IPA trusts the replica (since it signed the cert, I assume), but the replica doesn't trust the main IPA server. I guess the ZZ option would have shown me the failure that I missed in my initial ldapsearch tests. -Z[Z] Issue StartTLS (Transport Layer Security) extended operation. If you use -ZZ, the command will require the operation to be suc- cessful. i.e. use SSL, and force a successful handshake Anyway, what's the best way to remedy this in a way that makes IPA happy? (I've found that LDAP can have different requirements on which certs go where). I'm not sure. ipa-server-install/ipa-replica-prepare/ipa-replica-install is supposed to take care of installing the CA cert properly for you. If you try to hack it and install the CA cert manually, you will probably miss something else that ipa install did not do. I think the only way to ensure that you have a properly configured ipa server + replicas is to get all of the ipa commands completing successfully. Which means going back to the drawing board and starting over from
Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory
On Thu, 03 Apr 2014, Redmond, Stacy wrote: Yes, I did that, here is the log [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local@UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] [client 10.130.82.68] Credentials for HTTP/linuxtest1.sbx.local@UNIX have expired or will soon expire - now 1396556512 endtime 1396551629, referer: https://linuxtest1.sbx.local/ipa/xml [Thu Apr 03 13:21:52 2014] [error] ipa: INFO: admin@UNIX: ping(): SUCCESS [Thu Apr 03 13:21:55 2014] [error] ipa: INFO: admin@UNIX: trust_add(u'sbx.local', trust_type=u'ad', realm_admin=u'admsredmo01', realm_passwd=u'', range_size=20, all=False, raw=False, version=u'2.49'): NotFound No, you haven't. This is not the log entries I'd expect. Between ping() and trust_add() line there should be a lot of debug output from Samba Python code. -Original Message- From: Alexander Bokovoy [mailto:aboko...@redhat.com] Sent: Thursday, April 03, 2014 12:12 PM To: Redmond, Stacy Cc: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Unable to establish trust with FreeIPA and Active Directory On Thu, 03 Apr 2014, Redmond, Stacy wrote: I have this same exact issue. I have not only verified that DNS is functioning properly, I have also added the AD server to the local hosts file as is the reported fix for this issue and it still persists. add log level = 100 to [global] section in /usr/share/ipa/smb.conf.empty and try 'ipa trust-add' again. You'll get debug output in httpd's error_log. I'd like to see level 100 logs, they give a bit more details in case of SMB Python bindings. -- / Alexander Bokovoy -- / Alexander Bokovoy ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
