[Freeipa-users] Redhat/Centos iDM 3.0 to 3.1 upgrade fail
Carefully following the instructions here:https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.htmlI have split one of my Centis 6.6 based replicas from the main cluster of 4 IDM servers, fully disconnected it from current IDM infrastructure, converted it to a master CA, double checked that I have no dangling/tombstone entries pointing back to other cluster members, ipa-replica-manage list and ipa-replica-manage list-ruv both show no other masters, in short, made absolutely sure that this replica is now a standalone.I then applied the schema updates via the python script per the above referenced instructions, did “ipa-replica-prepare”, deployed a new Centos 7 vm, yum install ipa-server there, scp’d over the replica file.Next up, "ipa-replica-install --setup-ca”.And that’s where the story ends…..Done configuring directory server (dirsrv).Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/19]: creating certificate server user [2/19]: configuring certificate server instanceipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpM9BzPz' returned non-zero exit status 1Your system may be partly configured.Run /usr/sbin/ipa-server-install --uninstall to clean up.Configuration of CA failedI tried the workaround mentioned here:https://fedorahosted.org/pki/ticket/816updated /usr/share/pki/ca/conf/CS.cfg before running ipa-replica-installBut not luck.Anybody have a clue where I should look?Frompki-ca-spawn.20150114014019.log:2015-01-14 01:40:32 pkispawn : ERROR ... Exception from Java Configuration Servlet: Failed to obtain installation token from security domainand in/var/log/pki/pki-tomcat/ca/server I have:2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing valuemore info that might help…….[root@sso-centos7 pki]# certutil -L -d /var/lib/pki/pki-tomcat/aliasCertificate Nickname Trust Attributes SSL,S/MIME,JAR/XPIServer-Cert cert-pki-ca CTu,Cu,CuCertificate Authority - PLACEIQ.NET CT,c,My CS.cfg is attached. CS.cfg Description: Binary data Maybe the fact that my new server is looking at the same DNS and can see the SRV records for the current Centos 6.6/IDM 3.0 cluster is causing a problem ??Of course I have uninstalled and done this a zillion times:pkidestroy -s CA -i pki-tomcatrm -rf /var/log/pki/pki-tomcatrm -rf /etc/sysconfig/pki-tomcatrm -rf /etc/sysconfig/pki/tomcat/pki-tomcatrm -rf /var/lib/pki/pki-tomcatrm -rf /etc/pki/pki-tomcatI’m at a loss, no idea even where to look at this point.Thanks in advance for any clues you can provide.Jim Richard |PlaceIQ| Systems Administrator | jrichard@placeiq.com|+1 (646) 338-8905 -- 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] Can I revert back the hostname on client
Hi, Freeipa changes the hostname to FQDN. But in our exisitng set up that can cause issues . Can I revert back the hostname to previous value once the client installation is complete. I am fine with server having a FQDN. Thanks, Rakesh -- 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] Mount cifs share using kerberos
On Mon, 12 Jan 2015 09:46:37 +0100 John Obaterspok john.obaters...@gmail.com wrote: 2015-01-11 16:33 GMT+01:00 Jakub Hrozek jhro...@redhat.com: On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote: 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi gianluca.cec...@gmail.com: To get the whole root environment you have to run su - root did you try with it? ahh... that works fine Gianluca! Final question, if I have a file on the share like: [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt Should I be able to access it if I aquire an admin ticket? Currently I get Permission denied [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john) grupper=143444(john) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [john@ipaserver mountpoint]$ getfacl test.txt # file: test.txt # owner: root # group: admins user::rwx group::r-- other::--- [john@ipaserver mountpoint]$ id admin uid=143440(admin) gid=143440(admins) groups=143440(admins) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_MVjxTqf Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/my@my.lan [john@ipaserver mountpoint]$ cat test.txt cat: test.txt: Permission denied Looks like your account needs to be in the 'admins' group in order to access the file. Acquiring the admin ticket doesn't switch the user ID nor add you to the group.. I thought the krb5 mount option would allow ticked based access to the file. Is the purpose of the krb5 mount option just used during mounting of the share? Otherwise I see no difference compared to not using krb5 mount option!? You need to pass the 'multiuser' option at mount time for that, the default for cifs.ko is still to just use the mount credentials. See mount.cifs manpage, search for 'multiuser' Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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 updates from dhcpd refused
On 01/13/2015 12:35 PM, Mike wrote: Just a note to anyone else who may be interested. This may be obvious but it wasn't to me at first, The ipa dnszone-mod ... --update-policy=... command wipes out the existing BIND update policy. So what would seem to me to be the correct procedure is to do ipa dnszone-show --all first to get the existing policy. Then append the new policy to the existing. This is what ultimatley worked for me (all one line). ipa dnszone-mod inside.lan --update-policy=grant INSIDE.LAN krb5-self * A; grant INSIDE.LAN krb5-self * ; grant INSIDE.LAN krb5-self * SSHFP; grant dhcpupdate zonesub A; grant dhcpupdate zonesub TXT; grant dhcpupdate zonesub PTR; Would you mind contributing a howto solution to FreeIPA site? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS updates from dhcpd refused
On Tue, 13 Jan 2015, Petr Spacek wrote: On 13.1.2015 14:52, Mike wrote: Hi - FreeIPA newbie here trying to enable ddns updates from dhcpd to IPA. I don't know if this is an IPA or dhcpd issue but thought I'd ask here. I'm also not sure if TSIG the best, or only way to go. All machines are CentOS 7 with ipa 3.3.3, actually only one machine involved, IPA server and dhcpd are running on the same VM. I followed guide here: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG with one exception, I used grant dhcpupdate zonesub A; in the ipa dnszone-mod command. To test I did this: nsupdate -k /tmp/testkey update add newhost.inside.lan 86400 A 10.16.1.99 send nsupdate works as expected, both forward and reverse records are added. However updates from dhcpd are rejected, here's a snippet from two log files. Oh and raising the trace level with 'rndc trace 9' didn't reveal anything useful (to me anyway). tail -f /var/log/messages /var/named/data/named.run == /var/named/data/named.run == 12-Jan-2015 20:15:02.092 client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) == /var/log/messages == Jan 12 20:15:02 ds01 named[11065]: client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) Jan 12 20:15:02 ds01 dhcpd: No hostname for 10.16.1.203 Jan 12 20:15:02 ds01 dhcpd: DHCPREQUEST for 10.16.1.203 from 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: DHCPACK on 10.16.1.203 to 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: Unable to add forward map from nas2.inside.lan to 10.16.1.203: REFUSED dhcpd is supposed to do the same thing as nsupdate so this is weird. You can increase log level in BIND to 8: $ rndc trace 8 to get more information about the failure Alternative is to use tcpdump/wireshark and compare packages send by nsupdate and dhcpd to see where the difference is. Feel free to send me packet captures privately if you don't want to post them to mailing list. Have a nice day! Petr - Thanks for the suggestion, that helped me solve the problem. Turns out the difference is that dhcpd is also trying to add a TXT record which nsupdate was not (because I didn't tell it to). So adding grant dhcpupdate zonesub TXT; to the ipa dnszone-mod command fixes the problem. Actually it appears as though dhcpd tries to add a PTR record if the A and TXT are successful. So I think I need to add grant dhcpupdate zonesub PTR; to be complete. -- Thanks again, 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 updates from dhcpd refused
Just a note to anyone else who may be interested. This may be obvious but it wasn't to me at first, The ipa dnszone-mod ... --update-policy=... command wipes out the existing BIND update policy. So what would seem to me to be the correct procedure is to do ipa dnszone-show --all first to get the existing policy. Then append the new policy to the existing. This is what ultimatley worked for me (all one line). ipa dnszone-mod inside.lan --update-policy=grant INSIDE.LAN krb5-self * A; grant INSIDE.LAN krb5-self * ; grant INSIDE.LAN krb5-self * SSHFP; grant dhcpupdate zonesub A; grant dhcpupdate zonesub TXT; grant dhcpupdate zonesub PTR; -- 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] Issues with new install - Configuration of CA failed
I am having a very difficult time getting the ipa server installed on
our test server.
CentOS release 6.6 (Final)
Linux test1-vm.example.com 2.6.32-504.3.3.el6.x86_64 #1 SMP Wed Dec 17
01:55:02 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
ipa-server-3.0.0-42.el6.centos.x86_64
I tried to reinstall pki-selinux, reboot, relabel and that didn't help
yum reinstall pki-selinux
I reviewed a number of threads and didn't seem to see my issue of
Request:java.net.ConnectException: Connection refused at step 2/20
https://www.redhat.com/archives/freeipa-users/2014-April/msg00278.html
Any suggestions would be greatly appreciated.
I used: ipa-server-install --no-ntp
Continue to configure the system with these values? [no]: yes
The following operations may take some minutes to complete.
Please wait until the prompt is returned.
Configuring directory server for the CA (pkids): Estimated time 30 seconds
[1/3]: creating directory server user
[2/3]: creating directory server instance
[3/3]: restarting directory server
Done configuring directory server for the CA (pkids).
Configuring certificate server (pki-cad): Estimated time 3 minutes 30 seconds
[1/20]: creating certificate server user
[2/20]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
test1-vm.example.com -cs_port 9445 -client_certdb_dir /tmp/tmp-WQ28_w
-client_certdb_pwd -preop_pin MvLsuha0GPxvJSnYoL5u
-domain_name IPA -admin_user admin -admin_email root@localhost
-admin_ -agent_name ipa-ca-agent -agent_key_size 2048
-agent_key_type rsa -agent_cert_subject CN=ipa-ca-agent,O=EXAMPLE.COM
-ldap_host test1-vm.example.com -ldap_port 7389 -bind_dn cn=Directory
Manager -bind_ -base_dn o=ipaca -db_name ipaca
-key_size 2048 -key_type rsa -key_algorithm SHA256withRSA -save_p12
true -backup_pwd -subsystem_name pki-cad -token_name internal
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=EXAMPLE.COM
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=EXAMPLE.COM
-ca_server_cert_subject_name CN=test1-vm.example.com,O=EXAMPLE.COM
-ca_audit_signing_cert_subject_name CN=CA Audit,O=EXAMPLE.COM
-ca_sign_cert_subject_name CN=Certificate Authority,O=EXAMPLE.COM
-external false -clone false' returned non-zero exit status 255
Configuration of CA failed
install log:
[root@test1-vm log]# cat ipaserver-install.log
2015-01-13T19:47:59Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG httpd is not configured
2015-01-13T19:47:59Z DEBUG kadmin is not configured
2015-01-13T19:47:59Z DEBUG dirsrv is not configured
2015-01-13T19:47:59Z DEBUG pki-cad is not configured
2015-01-13T19:47:59Z DEBUG pki-tomcatd is not configured
2015-01-13T19:47:59Z DEBUG pkids is not configured
2015-01-13T19:47:59Z DEBUG install is not configured
2015-01-13T19:47:59Z DEBUG krb5kdc is not configured
2015-01-13T19:47:59Z DEBUG ntpd is not configured
2015-01-13T19:47:59Z DEBUG named is not configured
2015-01-13T19:47:59Z DEBUG ipa_memcached is not configured
2015-01-13T19:47:59Z DEBUG filestore is tracking no files
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa-client/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG /usr/sbin/ipa-server-install was invoked
with options: {'zone_refresh': 0, 'reverse_zone': None, 'realm_name':
None, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': False,
'subject': None, 'no_forwarders': False, 'persistent_search': True,
'ui_redirect': True, 'domain_name': None, 'idmax': 0, 'hbac_allow':
False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended':
False, 'selfsign': False, 'trust_sshfp': False, 'external_ca_file':
None, 'no_host_dns': False, 'http_pkcs12': None, 'zone_notif': False,
'forwarders': None, 'idstart': 184480, 'external_ca': False,
'ip_address': None, 'conf_ssh': True, 'serial_autoincrement': True,
'zonemgr': None, 'setup_dns': False, 'host_name': None, 'debug':
False, 'external_cert_file': None, 'uninstall': False}
2015-01-13T19:47:59Z DEBUG missing options might be asked for
interactively later
2015-01-13T19:47:59Z DEBUG Loading Index file from
'/var/lib/ipa/sysrestore/sysrestore.index'
2015-01-13T19:47:59Z DEBUG Loading StateFile from
'/var/lib/ipa/sysrestore/sysrestore.state'
2015-01-13T19:47:59Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS
2015-01-13T19:47:59Z DEBUG stdout=VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
_default_:8443 test1-vm.example.com (/etc/httpd/conf.d/nss.conf:84)
2015-01-13T19:47:59Z DEBUG stderr=Syntax OK
2015-01-13T19:48:02Z DEBUG Check if test1-vm.example.com is a primary
hostname for localhost
2015-01-13T19:48:02Z DEBUG Primary hostname for localhost: test1-vm.example.com
Re: [Freeipa-users] freeipa authentication token manipulation error
On Tue, Jan 13, 2015 at 12:48:18PM +0530, Rakesh Rajasekharan wrote: Does it work for the same user from the client if you reset password on the server, authenticate from the client and then force reset again on the server? When I force reset a user, he stil faces the same error token manipulation when tries to login to a client. However, when he tries getting into the server, he now gets prompted for the password change and is successfully able to get through. So, at this point we have a workaround though something seems not right at the clients. Can you add a new client and see whether it works there? Have you tried re-installing the client? Yes, I did try reinstalling but that did not help Sorry, I meant the full krb5_child.log ... This is how I get the logs in krb5_child. when a user tries to authenticate with the random password that I generated, WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro And on the krb5_child.log, these are the entries (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [main] (0x0400): Will perform password change (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x1000): Password change operation (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] This does not go beyond this. however, when i attempt another login , the logs start moving from this point( the time stamp start from 6:54 AM) WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro now the krb5_child.log adds following lines (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): krb5_child started. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x1000): total buffer size: [134]TEST (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): cmd [241] uid [71061] gid [71061] validate [true] enterprise principal [false] offline [false] UPN [hq-testu...@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): Will perform online auth (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [get_and_save_tgt] (0x0400): Attempting kinit for realm [TEST.COM] (Tue Jan 13 06:54:53 2015) [[sssd[krb5_child[23514 [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Tue Jan 13 06:54:53 2015) [[sssd[krb5_child[23514 [tgt_req_child] (0x1000): Password was expired (Tue Jan 13 06:54:56 2015)
Re: [Freeipa-users] freeipa authentication token manipulation error
On (13/01/15 12:48), Rakesh Rajasekharan wrote: This is how I get the logs in krb5_child. when a user tries to authenticate with the random password that I generated, WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro And on the krb5_child.log, these are the entries (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [main] (0x0400): Will perform password change (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x1000): Password change operation (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] I would expect at least next line: Received error code Are you sure there is no crash? Could you look into /var/log/messages? LS -- 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] Group Policy-like features in FreeIPA
On 12.1.2015 17:20, brendan kearney wrote: OpenAFS? If you insist on a replicated FS then try Gluster. Petr^2 Spacek On Jan 12, 2015 11:04 AM, Craig White cwh...@skytouchtechnology.com wrote: *From:* freeipa-users-boun...@redhat.com [mailto: freeipa-users-boun...@redhat.com] *On Behalf Of *Dale Macartney *Sent:* Sunday, January 11, 2015 2:16 PM *To:* freeipa-users@redhat.com *Subject:* [Freeipa-users] Group Policy-like features in FreeIPA Morning folks I am currently working on a little pet project which I think some would find useful. I would like to introduce some group policy like functionality into a FreeIPA domain. For example: In an environment running FreeIPA Server with Fedora or RHEL based workstations, I would like to be able to introduce a few extra features which initially may be pushed via a login script (maybe even configure a dbus session as well, who knows?). My intentions here would be to be able to apply host specific policies as well as have the option for user specific policies which would be applied when the user logs in. Practically speaking, adding an attribute to LDAP to specify a login script file name is easy enough, however actually fetching this is where I am hoping for a bit of brain storming. My thoughts would be the local user would fetch the name of the login script via ldap, and then perhaps fetch the file from a shared resource on the FreeIPA masters in order to be executed locally. LDAP is obviously replicated, however to my knowledge, there is no file synchronization between masters. I am thinking something similar to the MS equivalent of the SYSVOL data that replicates between MS Domain Controllers. One option would be to store all data within LDAP, however I've seen many scenarios where admins store CD ISO's in replicated domain data, so I am not certain this would be the best option. With this replicated data folder, I would be able to store centrally managed scripts which would be used for hosts or users, and then configure the default user template on each workstation (/etc/skel/) to add the login script file name which would be fetched from the users LDAP attributes. Real world usability for what I am thinking of is a way to manage users who can have their corporate email mailbox configured on login, automatically setting the users session to point to an internal SSO enabled proxy server or perhaps any other number of things which an admin may wish to achieve without the need to manually do the work themselves. Has anyone undertaken a similar scenario in their environments or would perhaps have any suggestions on how to manage the centrally accessible file stores? Many thanks Specifically, I haven’t fully implemented what you are asking but obviously parts and pieces yes. One of the best features of Linux and all of its various toolsets is that one are quite so overarching and the objectives are more focused. String them together and you have a working tool set. As a system administrator, you learn to pipe grep output to awk or sed or cut etc. SYSVOL ó NFS and if that doesn’t do it for you, check out Unison. I guess one of the temptations of FreeIPA is to try to make it exactly like active directory. The FreeIPA developers are already doing an amazing job without a ton of manpower. Craig -- 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 -- 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
[Freeipa-users] DNS updates from dhcpd refused
Hi - FreeIPA newbie here trying to enable ddns updates from dhcpd to IPA. I don't know if this is an IPA or dhcpd issue but thought I'd ask here. I'm also not sure if TSIG the best, or only way to go. All machines are CentOS 7 with ipa 3.3.3, actually only one machine involved, IPA server and dhcpd are running on the same VM. I followed guide here: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG with one exception, I used grant dhcpupdate zonesub A; in the ipa dnszone-mod command. To test I did this: nsupdate -k /tmp/testkey update add newhost.inside.lan 86400 A 10.16.1.99 send nsupdate works as expected, both forward and reverse records are added. However updates from dhcpd are rejected, here's a snippet from two log files. Oh and raising the trace level with 'rndc trace 9' didn't reveal anything useful (to me anyway). tail -f /var/log/messages /var/named/data/named.run == /var/named/data/named.run == 12-Jan-2015 20:15:02.092 client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) == /var/log/messages == Jan 12 20:15:02 ds01 named[11065]: client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) Jan 12 20:15:02 ds01 dhcpd: No hostname for 10.16.1.203 Jan 12 20:15:02 ds01 dhcpd: DHCPREQUEST for 10.16.1.203 from 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: DHCPACK on 10.16.1.203 to 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: Unable to add forward map from nas2.inside.lan to 10.16.1.203: REFUSED -- Thanks, 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 updates from dhcpd refused
On 13.1.2015 14:52, Mike wrote: Hi - FreeIPA newbie here trying to enable ddns updates from dhcpd to IPA. I don't know if this is an IPA or dhcpd issue but thought I'd ask here. I'm also not sure if TSIG the best, or only way to go. All machines are CentOS 7 with ipa 3.3.3, actually only one machine involved, IPA server and dhcpd are running on the same VM. I followed guide here: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG with one exception, I used grant dhcpupdate zonesub A; in the ipa dnszone-mod command. To test I did this: nsupdate -k /tmp/testkey update add newhost.inside.lan 86400 A 10.16.1.99 send nsupdate works as expected, both forward and reverse records are added. However updates from dhcpd are rejected, here's a snippet from two log files. Oh and raising the trace level with 'rndc trace 9' didn't reveal anything useful (to me anyway). tail -f /var/log/messages /var/named/data/named.run == /var/named/data/named.run == 12-Jan-2015 20:15:02.092 client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) == /var/log/messages == Jan 12 20:15:02 ds01 named[11065]: client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) Jan 12 20:15:02 ds01 dhcpd: No hostname for 10.16.1.203 Jan 12 20:15:02 ds01 dhcpd: DHCPREQUEST for 10.16.1.203 from 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: DHCPACK on 10.16.1.203 to 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: Unable to add forward map from nas2.inside.lan to 10.16.1.203: REFUSED dhcpd is supposed to do the same thing as nsupdate so this is weird. You can increase log level in BIND to 8: $ rndc trace 8 to get more information about the failure Alternative is to use tcpdump/wireshark and compare packages send by nsupdate and dhcpd to see where the difference is. Feel free to send me packet captures privately if you don't want to post them to mailing list. Have a nice day! -- 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
Re: [Freeipa-users] freeipa authentication token manipulation error
Thanks, that worked.. users now able to get the password changed with any issues... Will do few more testing on this but at this point looks like that was the issue ~Rakesh On Tue, Jan 13, 2015 at 1:52 PM, Sumit Bose sb...@redhat.com wrote: On Tue, Jan 13, 2015 at 12:48:18PM +0530, Rakesh Rajasekharan wrote: Does it work for the same user from the client if you reset password on the server, authenticate from the client and then force reset again on the server? When I force reset a user, he stil faces the same error token manipulation when tries to login to a client. However, when he tries getting into the server, he now gets prompted for the password change and is successfully able to get through. So, at this point we have a workaround though something seems not right at the clients. Can you add a new client and see whether it works there? Have you tried re-installing the client? Yes, I did try reinstalling but that did not help Sorry, I meant the full krb5_child.log ... This is how I get the logs in krb5_child. when a user tries to authenticate with the random password that I generated, WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro And on the krb5_child.log, these are the entries (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [main] (0x0400): Will perform password change (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x1000): Password change operation (Tue Jan 13 06:47:39 2015) [[sssd[krb5_child[18004 [changepw_child] (0x0400): Attempting kinit for realm [TEST.COM] This does not go beyond this. however, when i attempt another login , the logs start moving from this point( the time stamp start from 6:54 AM) WARNING: Your password has expired. You must change your password now and login again! Changing password for user hq-testuser. Current Password: New password: Retype new password: passwd: Authentication token manipulation erro now the krb5_child.log adds following lines (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): krb5_child started. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x1000): total buffer size: [134]TEST (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): cmd [241] uid [71061] gid [71061] validate [true] enterprise principal [false] offline [false] UPN [hq-testu...@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_71061_XX] keytab: [/etc/krb5.keytab] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ qa-dummy-int.test@test.com] (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [match_principal] (0x1000): Principal matched to the sample (host/ qa-dummy-int.test@test.com). (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [check_fast_ccache] (0x0200): FAST TGT is still valid. (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [main] (0x0400): Will perform online auth (Tue Jan 13 06:54:52 2015) [[sssd[krb5_child[23514 [tgt_req_child] (0x1000): Attempting to get a TGT (Tue Jan 13 06:54:52 2015)
Re: [Freeipa-users] I think I trashed my FreeIPA CA - how to recover?
On Jan 13, 2015, at 1:56 PM, Brian Topping brian.topp...@gmail.com wrote: Hi folks, really pleased with the latest versions of FreeIPA. Very robust, quite impressive! In the process of setting it up, I ended up having to move servers a couple of times. The original server is gone, just replicas that installed cleanly with each other. Ok, I think I have this sorted -- somewhat. After pawing through the Tomcat configuration for Dogtag, I traced back to the pki-tomcatd@pki-tomcat.service mailto:pki-tomcatd@pki-tomcat.service not running. Once that started, the relevant information was available to the UI. There are a sufficient number of certificates that I think everything is in order. Whew. What I realize now is the certificate CRL points to the server that no longer exists and I'd like to get that cleaned up. I found http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master, is that relevant for my situation? Thanks, Brian-- 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 fails when using --setup-ca
On 01/12/2015 03:53 PM, dbisc...@hrz.uni-kassel.de wrote:
Hi,
no ideas about this one?
I'm unsure if I did something wrong, but since I installed both systems the
same way, I really don't know, what could be wrong.
One thing that may be related: The working system (the one that doesn't fail
to
create a replica with --setup-ca) went productive in April 2014, the one
that
fails in September 2014. In between were several updates to the ipa-server
package, including one related to Dogtag (Proxy calls to
/ca/ee/ca/profileSubmit to PKI to enable installation of replicas with Dogtag
10 PKI (#1083878)). Can this cause errors like the one I observe?
That's a good guess. Installing a RHEL/CentOS 7.0 replica with having such
server without this update as the master would indeed cause a failure. Did you
try updating it?
Something else I may want to look into? My installations are pretty much
standard, except that I use an external DNS and have SELinux disabled.
If the referred update does not help, we would need to see full
ipareplica-install.log and PKI logs (/var/log/pki/) on replica to continue with
debug.
Best regards,
--Daniel.
On Tue, 6 Jan 2015, dbisc...@hrz.uni-kassel.de wrote:
I have two small FreeIPA installations (for two different realms), both with
CentOS 6/FreeIPA 3.0.0-42. After running them both with only one master
server each for a while, I attempted to extend both installations with one
replica each.
Doing a
ipa-replica-install --setup-ca /var/lib/ipa/replica-info-...
worked fine for one of the installations, but failed for the other:
---
[...]
[3/17]: configuring certificate server instance ipa : CRITICAL failed to
configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent ConfigureCA
-cs_hostname xxx -cs_port 9445 -client_certdb_dir /tmp/tmp-YsXvhP
-client_certdb_pwd -preop_pin vJl0m3xc9Oz7b1fIgttD -domain_name IPA
-admin_user admin -admin_email root@localhost -admin_password
-agent_name ipa-ca-agent -agent_key_size 2048 -agent_key_type rsa
-agent_cert_subject CN=ipa-ca-agent,O=YYY -ldap_host xxx -ldap_port 7389
-bind_dn cn=Directory Manager -bind_password -base_dn o=ipaca
-db_name ipaca -key_size 2048 -key_type rsa -key_algorithm SHA256withRSA
-save_p12 true -backup_pwd -subsystem_name pki-cad -token_name
internal -ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_subsystem_cert_subject_name CN=CA Subsystem,O=YYY
-ca_ocsp_cert_subject_name CN=OCSP Subsystem,O=YYY
-ca_server_cert_subject_name CN=xxx,O=YYY -ca_audit_signing_cert_subject_name
CN=CA Audit,O=YYY -ca_sign_cert_subject_name CN=Certificate Authority,O=YYY
-external false -clone true -clone_p12_file ca.p12 -clone_p12_password
-sd_hostname mmm -sd_admin_port 443 -sd_admin_name admin
-sd_admin_password -clone_start_tls true -clone_uri https://mmm:443'
returned non-zero exit status 255
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
---
/var/log/ipareplica-install.log:
---
[...]
Error in DomainPanel(): updateStatus value is null
ERROR: ConfigureCA: DomainPanel() failure
ERROR: unable to create CA
###
2015-01-06T13:36:25Z DEBUG stderr=
2015-01-06T13:36:25Z CRITICAL failed to configure ca instance Command
'/usr/bin/perl /usr/bin/pkisilent ConfigureCA -cs_hostname
2015-01-06T13:36:25Z INFO File
/usr/lib/python2.6/site-packages/ipaserver/install/installutils.py, line
614, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 476, in main
(CA, cs) = cainstance.install_replica_ca(config)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 1626, in install_replica_ca
subject_base=config.subject_base)
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 626, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.6/site-packages/ipaserver/install/service.py, line
358, in start_creation
method()
File /usr/lib/python2.6/site-packages/ipaserver/install/cainstance.py,
line 888, in __configure_instance
raise RuntimeError('Configuration of CA failed')
2015-01-06T13:36:25Z INFO The ipa-replica-install command failed, exception:
RuntimeError: Configuration of CA failed
---
Omitting --setup-ca lets me successfully install a working replica server.
The problem appears to be my installation (since the other one works) -
however: Both (intended) replica servers are nearly identical (operating
system version, installed packages, etc.).
My understanding is that a replica without a CA is not a 100%-clone of a IPA
master, right? What are the downsides of having a replica without a CA?
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more
Re: [Freeipa-users] I think I trashed my FreeIPA CA - how to recover?
On 01/13/2015 10:38 AM, Brian Topping wrote: On Jan 13, 2015, at 1:56 PM, Brian Topping brian.topp...@gmail.com wrote: Hi folks, really pleased with the latest versions of FreeIPA. Very robust, quite impressive! Good to hear! :-) In the process of setting it up, I ended up having to move servers a couple of times. The original server is gone, just replicas that installed cleanly with each other. Hmm, I hoped that after FreeIPA 3.2 (https://fedorahosted.org/freeipa/ticket/2879), FreeIPA should before warn removing the last DNS/CA from the realm. If may indeed be a bug. The point is that it is hard to recover when there is no master with PKI configured and backup to use as some information are only on the PKI masters, like the CA private key or other subsystem cert private keys. Ok, I think I have this sorted -- somewhat. After pawing through the Tomcat configuration for Dogtag, I traced back to the pki-tomcatd@pki-tomcat.service mailto:pki-tomcatd@pki-tomcat.service not running. Once that started, the relevant information was available to the UI. There are a sufficient number of certificates that I think everything is in order. Whew. Sounds promising. What I realize now is the certificate CRL points to the server that no longer exists and I'd like to get that cleaned up. I found http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master, is that relevant for my situation? Yes, this is the procedure to follow for servers older than FreeIPA 4.1. Jan is that correct? If yes, the page deserves a warning/update. -- 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 updates from dhcpd refused
-Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Mike Sent: Tuesday, January 13, 2015 6:52 AM To: freeipa-users@redhat.com Subject: [Freeipa-users] DNS updates from dhcpd refused Hi - FreeIPA newbie here trying to enable ddns updates from dhcpd to IPA. I don't know if this is an IPA or dhcpd issue but thought I'd ask here. I'm also not sure if TSIG the best, or only way to go. All machines are CentOS 7 with ipa 3.3.3, actually only one machine involved, IPA server and dhcpd are running on the same VM. I followed guide here: http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG with one exception, I used grant dhcpupdate zonesub A; in the ipa dnszone-mod command. To test I did this: nsupdate -k /tmp/testkey update add newhost.inside.lan 86400 A 10.16.1.99 send nsupdate works as expected, both forward and reverse records are added. However updates from dhcpd are rejected, here's a snippet from two log files. Oh and raising the trace level with 'rndc trace 9' didn't reveal anything useful (to me anyway). tail -f /var/log/messages /var/named/data/named.run == /var/named/data/named.run == 12-Jan-2015 20:15:02.092 client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) == /var/log/messages == Jan 12 20:15:02 ds01 named[11065]: client 10.16.1.10#10196/key dhcpupdate: updating zone 'inside.lan/IN': update failed: rejected by secure update (REFUSED) Jan 12 20:15:02 ds01 dhcpd: No hostname for 10.16.1.203 Jan 12 20:15:02 ds01 dhcpd: DHCPREQUEST for 10.16.1.203 from 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: DHCPACK on 10.16.1.203 to 52:54:00:4a:44:f7 (nas2) via eth0 Jan 12 20:15:02 ds01 dhcpd: Unable to add forward map from nas2.inside.lan to 10.16.1.203: REFUSED Mike, Please be sure to post when you do come to a resolution on this, it may be something I want to do - at least in my home setup. Craig -- 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] invalid cn=CACert,cn=ipa,cn=etc entry
Hi All, We run a FreeIPA server (3.0.0) on SL6. Fedora 21 clients are unable to complete freeipa-client-install. It fails due to a parsing error of the CA certificate. I tracked down the error and it seems our cn=CACert,cn=ipa,cn=etc entry is invalid. This is the ldif: dn: cn=CACert,cn=ipa,cn=etc,dc=xyz,dc=abc, dc=de objectClass: top objectClass: pkiCA objectClass: nsContainer cn: CAcert cACertificate;binary:: (this fields contains base64 encoded data, not binary data) I modified the certstore.py script and changed line 299 from cert = entry.single_value['cACertificate;binary'] to: cert = base64.b64decode(entry.single_value['cACertificate;binary']) after that ipa-client-install completes without a problem. We run FreeIPA for a few years now so perhaps something went wrong with an update of the server at some point and the cn=CACert entry was not updated correctly. What's the valid format of the CACert entry in LDAP? Can we change it to binary without other clients ending up in trouble? Guessing from the get_ca_certs function we also want other attributes like ipaCertSubject, ipaCertIssuerSerial,... These are also missing in our server but perhaps these were only added in later FreeIPA server versions. Thanks, Bram -- 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 updates from dhcpd refused
On Tue, 13 Jan 2015, Dmitri Pal wrote: On 01/13/2015 12:35 PM, Mike wrote: Just a note to anyone else who may be interested. This may be obvious but it wasn't to me at first, The ipa dnszone-mod ... --update-policy=... command wipes out the existing BIND update policy. So what would seem to me to be the correct procedure is to do ipa dnszone-show --all first to get the existing policy. Then append the new policy to the existing. This is what ultimatley worked for me (all one line). ipa dnszone-mod inside.lan --update-policy=grant INSIDE.LAN krb5-self * A; grant INSIDE.LAN krb5-self * ; grant INSIDE.LAN krb5-self * SSHFP; grant dhcpupdate zonesub A; grant dhcpupdate zonesub TXT; grant dhcpupdate zonesub PTR; Would you mind contributing a howto solution to FreeIPA site? Wouldn't mind at all however the Howto I used (http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG) is mostly correct, only three errors that I'm aware of. And it is a bit brief, there are a few things I could add. Should I just follow up off list with updates/changes? -- 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 updates from dhcpd refused
On 01/13/2015 01:41 PM, Mike wrote: On Tue, 13 Jan 2015, Dmitri Pal wrote: On 01/13/2015 12:35 PM, Mike wrote: Just a note to anyone else who may be interested. This may be obvious but it wasn't to me at first, The ipa dnszone-mod ... --update-policy=... command wipes out the existing BIND update policy. So what would seem to me to be the correct procedure is to do ipa dnszone-show --all first to get the existing policy. Then append the new policy to the existing. This is what ultimatley worked for me (all one line). ipa dnszone-mod inside.lan --update-policy=grant INSIDE.LAN krb5-self * A; grant INSIDE.LAN krb5-self * ; grant INSIDE.LAN krb5-self * SSHFP; grant dhcpupdate zonesub A; grant dhcpupdate zonesub TXT; grant dhcpupdate zonesub PTR; Would you mind contributing a howto solution to FreeIPA site? Wouldn't mind at all however the Howto I used (http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG) is mostly correct, only three errors that I'm aware of. And it is a bit brief, there are a few things I could add. Should I just follow up off list with updates/changes? -- Mike Thanks! Petr, Martin, what do you think is the best approach, for Mike just edit the page or send corrections off list? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
