[Freeipa-users] How to backup / restore the FreeIPA server?
Hi guys, We are going to use the FreeIPA v2.2.0 (the latest one available on CentOS 6.3) and would like to know if there is a way to do a complete backup / restore of the server database for disaster recovery purposes? I have been able to successfully export the userRoot db ldif via db2ldif, make some changes, then import the ldif via ldif2db. However when I try to build a new server with the same hostname, then import the ldif, that does not work. The import is successfull, however when trying to log in to IPA web GUI, I get an error that the admin password has expired. Here is an output when tring to change the password (I have restarted krb5kdc service at this point, as it was coming up with a different error): KRB5_TRACE=/dev/stdout kinit admin [10814] 1356353589.809893: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.871805: Sending request (176 bytes) to CO.YB.LMAX [10814] 1356353589.879177: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353589.09: Received answer from dgram 10.81.10.234:88 [10814] 1356353589.93: Response was not from master KDC [10814] 1356353589.888941: Received error from KDC: -1765328361/Password has expired [10814] 1356353589.888969: Retrying AS request with master KDC [10814] 1356353589.888976: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.889033: Sending request (176 bytes) to CO.YB.LMAX (master) [10814] 1356353589.889087: Principal expired; getting changepw ticket [10814] 1356353589.889111: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.889148: Setting initial creds service to [10814] 1356353589.889208: Sending request (174 bytes) to CO.YB.LMAX [10814] 1356353589.889516: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353589.901098: Received answer from dgram 10.81.10.234:88 [10814] 1356353589.901326: Response was not from master KDC [10814] 1356353589.901340: Received error from KDC: -1765328359/Additional pre-authentication required [10814] 1356353589.901596: Processing preauth types: 2, 136, 19, 133 [10814] 1356353589.901818: Selected etype info: etype aes256-cts, salt ^XEd/E2,L]'Zs), params [10814] 1356353589.901825: Received cookie: MIT Password for ad...@co.yb.lmax: [10814] 1356353596.402451: AS key obtained for encrypted timestamp: aes256-cts/78C9 [10814] 1356353596.402608: Encrypted timestamp (for 1356353596.402519): plain 301AA011180F32303132313232343132353331365AA1050203062457, encrypted 491EF490A7BFF756A7681BE9271E7925CCA41CC95916282FEFC3375FFBDC0B2A2E18B8501E81E1E14310762BC15351FE549633ABAB0CAB53 [10814] 1356353596.402627: Produced preauth for next request: 133, 2 [10814] 1356353596.402648: Sending request (269 bytes) to CO.YB.LMAX [10814] 1356353596.404303: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353596.447924: Received answer from dgram 10.81.10.234:88 [10814] 1356353596.448011: Response was not from master KDC [10814] 1356353596.448077: Processing preauth types: 19 [10814] 1356353596.448094: Selected etype info: etype aes256-cts, salt ^XEd/E2,L]'Zs), params [10814] 1356353596.448105: Produced preauth for next request: (empty) [10814] 1356353596.448116: AS key determined by preauth: aes256-cts/78C9 [10814] 1356353596.448295: Decrypted AS reply; session key is: aes256-cts/A68E [10814] 1356353596.448376: FAST negotiation: available [10814] 1356353596.448483: Attempting password change; 3 tries remaining Password expired. You must change it now. Enter new password: Enter it again: [10814] 1356353604.147282: Creating authenticator for ad...@co.yb.lmax - kadmin/chang...@co.yb.lmax, seqnum 0, subkey aes256-cts/E782, session key aes256-cts/A68E [10814] 1356353604.148689: Sending initial UDP request to dgram 10.81.10.234:464 [10814] 1356353604.154628: Received answer from dgram 10.81.10.234:464 kinit: Password change failed while getting initial credentials Thanks in advance for your help Viktor Mendes Systems Administrator viktor.men...@lmax.com | http://www.LMAX.com LMAX, Yellow Building, 1a Nicholas Road, London. W11 4AN FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved. The information in this email is not directed at residents of the United States of America or any other jurisdiction where trading in CFDs and/or FX is restricted or prohibited by local laws or regulations. The information in this email and any attachment is confidential and is intended only for the named recipient(s). The email may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not the intended recipient please notify the sender immediately and delete any copies of this message. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. LMAX operates a multilateral trading
[Freeipa-users] if passsyncservice starts , does that mean SSL is ok?
This soudns like SSL is correctly configured is the service continues to run, ratehr than stopping right away. if that's corret, my problem is someplae else (unsername, hostname, etc.) Is that correct? http://directory.fedoraproject.org/wiki/Howto:WindowsSync#Configuring_PassSync excerpt: *NOTE: PassSync will not work until TLS/SSL is configured.* The passsync.log will contain errors about SSL initialization until SSL is properly configured, and the service will not start. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] How to backup / restore the FreeIPA server?
On 12/24/2012 08:11 AM, Viktor Mendes wrote: Hi guys, We are going to use the FreeIPA v2.2.0 (the latest one available on CentOS 6.3) and would like to know if there is a way to do a complete backup / restore of the server database for disaster recovery purposes? Please see the thread about Backup and Restore earlier this month. https://www.redhat.com/archives/freeipa-users/2012-December/msg00118.html I have been able to successfully export the userRoot db ldif via db2ldif, make some changes, then import the ldif via ldif2db. However when I try to build a new server with the same hostname, then import the ldif, that does not work. The import is successfull, however when trying to log in to IPA web GUI, I get an error that the admin password has expired. Here is an output when tring to change the password (I have restarted krb5kdc service at this point, as it was coming up with a different error): KRB5_TRACE=/dev/stdout kinit admin [10814] 1356353589.809893: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.871805: Sending request (176 bytes) to CO.YB.LMAX [10814] 1356353589.879177: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353589.09: Received answer from dgram 10.81.10.234:88 [10814] 1356353589.93: Response was not from master KDC [10814] 1356353589.888941: Received error from KDC: -1765328361/Password has expired [10814] 1356353589.888969: Retrying AS request with master KDC [10814] 1356353589.888976: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.889033: Sending request (176 bytes) to CO.YB.LMAX (master) [10814] 1356353589.889087: Principal expired; getting changepw ticket [10814] 1356353589.889111: Getting initial credentials for ad...@co.yb.lmax [10814] 1356353589.889148: Setting initial creds service to [10814] 1356353589.889208: Sending request (174 bytes) to CO.YB.LMAX [10814] 1356353589.889516: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353589.901098: Received answer from dgram 10.81.10.234:88 [10814] 1356353589.901326: Response was not from master KDC [10814] 1356353589.901340: Received error from KDC: -1765328359/Additional pre-authentication required [10814] 1356353589.901596: Processing preauth types: 2, 136, 19, 133 [10814] 1356353589.901818: Selected etype info: etype aes256-cts, salt ^XEd/E2,L]'Zs), params [10814] 1356353589.901825: Received cookie: MIT Password for ad...@co.yb.lmax: [10814] 1356353596.402451: AS key obtained for encrypted timestamp: aes256-cts/78C9 [10814] 1356353596.402608: Encrypted timestamp (for 1356353596.402519): plain 301AA011180F32303132313232343132353331365AA1050203062457, encrypted 491EF490A7BFF756A7681BE9271E7925CCA41CC95916282FEFC3375FFBDC0B2A2E18B8501E81E1E14310762BC15351FE549633ABAB0CAB53 [10814] 1356353596.402627: Produced preauth for next request: 133, 2 [10814] 1356353596.402648: Sending request (269 bytes) to CO.YB.LMAX [10814] 1356353596.404303: Sending initial UDP request to dgram 10.81.10.234:88 [10814] 1356353596.447924: Received answer from dgram 10.81.10.234:88 [10814] 1356353596.448011: Response was not from master KDC [10814] 1356353596.448077: Processing preauth types: 19 [10814] 1356353596.448094: Selected etype info: etype aes256-cts, salt ^XEd/E2,L]'Zs), params [10814] 1356353596.448105: Produced preauth for next request: (empty) [10814] 1356353596.448116: AS key determined by preauth: aes256-cts/78C9 [10814] 1356353596.448295: Decrypted AS reply; session key is: aes256-cts/A68E [10814] 1356353596.448376: FAST negotiation: available [10814] 1356353596.448483: Attempting password change; 3 tries remaining Password expired. You must change it now. Enter new password: Enter it again: [10814] 1356353604.147282: Creating authenticator for ad...@co.yb.lmax - kadmin/chang...@co.yb.lmax, seqnum 0, subkey aes256-cts/E782, session key aes256-cts/A68E [10814] 1356353604.148689: Sending initial UDP request to dgram 10.81.10.234:464 [10814] 1356353604.154628: Received answer from dgram 10.81.10.234:464 kinit: Password change failed while getting initial credentials Thanks in advance for your help Viktor Mendes Systems Administrator viktor.men...@lmax.com | http://www.LMAX.com LMAX, Yellow Building, 1a Nicholas Road, London. W11 4AN FX and CFDs are leveraged products that can result in losses exceeding your deposit. They are not suitable for everyone so please ensure you fully understand the risks involved. The information in this email is not directed at residents of the United States of America or any other jurisdiction where trading in CFDs and/or FX is restricted or prohibited by local laws or regulations. The information in this email and any attachment is confidential and is intended only for the named recipient(s). The email may not be disclosed or used by any person other than the addressee, nor may it be copied in
[Freeipa-users] solved: here are some additional passsync notes
I'd love some feedback on these. They seemed to work for me.Thanks! Introduction This guide starts at the point where your freeipa server is correctly replicating accounts from a windows active directory server. The following steps are intended to help you roll out the passync software to all of your domain controllers. Detailed descriptions of how the software works are available from people far more competent than myself. I’m just covering some installation tips. One thing that really screwed me up is that there are great passsync docs for 389 directory server and great passsync docs for freeipa server. They are similar. They are NOT interchangeable. When using freeipa server stick with freeipa docs . I know this seems obvious, but when passsync doesn’t work the first time, my instinct is to cast about on google for things that seem to be related. When you find the 389 server docs under those circumstances and try to apply them to freeipa, you find a rathole. Getting started: It’s theoretically possible to get the passsync to work on the first attempt. I’ve just never done it. In order for that to work, you have to have exactly the right values ready to go when you run the passsync installer. The installer has input fields for the following items: verifying the hostname, username password and search base values hostname: FQDN of the freeipa server port: 636 username: uid=passsync,cn=sysaccounts,cn=etc,dc=xxx,dc=xxx password: password cert token : tried it with and without the /etc/dirsrv/slapd-instance/pwdfile.txt contents serach base=cn=users,cn=accounts,dc=inframax,dc=ncare The best tool I found in windows for checking the passsync installation settings is ldp. First I’ll talk about verifying the easy stuff (hostname, username, password, search base). run notepad on the windows server and put in the values you’re going to use before running the passsync installer. Then run ldp.exe and use the values from notepad and the steps below to verify the hostname, username, password and search base. ldp.exe connection connect enter the freeipa server hostname in the server field enter port 636 (non-ssl port) in the port field check the SSL box click OK connection bind select the 'simple bind' radio button enter the DN for the passsync account on the freeipa server in the userfield. this is uid=passsync,cn=sysaccounts,cn=etc,dc=domain,dc=domaintld by default enter the password for the passsync account in the password field click ok select view tree and make sure you can browse the tree in the ipa server. browse to the subtree that you're going to use for search base and make sure you see your replicated accounts in that container. if you can, then the values you used for the hostname, username, password and search base are all correct. It also means that the ca.crt file you imported for ldap account syunchronization is working correctly. NOTE: I left cert token empty. it seems to be used for encrypting the certificate db in c:\program files\389 directory password synchronization. That can be done after you get password synchronization working. Installing Passsync: Now we’ve done a bunch of work to check our values, but we haven’t accomplished anything. So go ahead and run the passsync msi installer and enter your values into the appropriate fields. The installer will create files, directories and registry stuff, but we’re not nearly done. Step 5 in the link below seems to have the correct steps. Be sure to import the same certificate that you imported in the account synchronization process. I got mine with wget http://iapserver/ipa/config/ca.crt. https://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/pass-sync.html One mroe thing before rebooting, use regedit to change the value of HKLM-Software-PasswordSync “Log Level” from 0 to 1. If everything works and you don’t need it, great! If the stars line up, you’ve put good values into the passsync installer, imported the freeipa servers certificate into the cert DB that passsync uses and the installer registered a new dll to capture password change events. You need to reboot the server to get the dll registration to take effect. After it restarts, change the password on an account that’s being replicated to free ipa. use notepad to open the file c:\program files\389 directory password synchronization\ passsync.txt if the passhook.dll is working correctly, you’ll see an entry like: ‘1 new entries loaded from data file’ If ssl is working correctly, you’ll be able to log into the freeipa server with the test account and newly changed password. Ifit doesn’t work, verify your cert and your values with ldp.exe. I just don’t have anything better that that yet. This takes me to the point where I’d love more tools to troubleshoot the problem. Other things I’ve tried: 1) UAC. I disable it, but I’d love some feedback on whether or not that’s required on win 2k8R2. 2) some of my DCs have
Re: [Freeipa-users] Does Solaris 11 work as client to IPA server?
Here is a step by step instruction for a Solaris 11 machine as client to a IPA server based on the default DUAProfile. Console login works, su - and ssh. Home directories automounted have the correct permissions. The automount does not use wildcards since i had issues of the whole /home being grabbed by autofs and thus making local users home directories unavalable. This can probably be solved by someone with more extensive experience of Solaris autofs. I am working on a instruction based on Sigbjorn Lie's DUAProfile and added security and will post it too shortly. First make sure that the Solaris 11 machine are using the proper DNS and NTP servers. On the IPA server or Client run: ipa host-add --force --ip-address=192.168.0.1 solaris.example.com ipa-getkeytab -s ipaserver.example.com -p host/solaris.example.com -k /tmp/solaris.keytab Move the keytab to the Solaris machine /etc/krb5/krb5.keytab Make sure it have the proper owner and permissions: chown root:sys /etc/krb5/krb5.keytab chmod 700 /etc/krb5/krb5.keytab Edit /etc/nsswitch.ldap, replace ldap with dns from the hosts and ipnodes lines: hosts: files dns ipnodes:files dns Edit /etc/krb5/krb5.conf: [libdefaults] default_realm = EXAMPLE.COM verify_ap_req_nofail = false [realms] EXAMPLE.COM = { kdc = ipaserver.example.com admin_server = ipaserver.example.com } [domain_realm] example.com = EXAMPLE.COM .example.com = EXAMPLE.COM Run the ldapclient with the default DUAProfile. The -a domainName= example.com is needed so that ldapclient does not stop and complain about missing nisdomain name. ldapclient -v init -a profilename=default -a domainName=example.com ipaserver.example.com In Solaris 11.1 the pam configuration have changed but for simplicity i still use the /etc/pam.conf: login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth sufficient pam_krb5.so.1 try_first_pass login auth required pam_unix_auth.so.1 login auth required pam_dial_auth.so.1 other auth requisite pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1 other account requisite pam_roles.so.1 other account requiredpam_unix_account.so.1 other account requiredpam_krb5.so.1 other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 For NFS and automount to work: In /etc/nfssec.conf enable these: krb5390003 kerberos_v5 default - # RPCSEC_GSS krb5i 390004 kerberos_v5 default integrity # RPCSEC_GSS krb5p 390005 kerberos_v5 default privacy # RPCSEC_GSS sharectl set -p nfsmapid_domain=example.com nfs If autofs is not on: svcadm enable system/filesystem/autofs:default In /etc/auto_home: testuseripaserver.example.com:/home/testuser From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Johan Petersson [johan.peters...@sscspace.com] Sent: Saturday, December 22, 2012 13:14 To: d...@redhat.com; freeipa-users@redhat.com Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? Hi, yes of course i can document it properly as soon as i have checked everything. I will send it to you so you can review it. Regards, Johan. From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Dmitri Pal [d...@redhat.com] Sent: Friday, December 21, 2012 23:39 To: freeipa-users@redhat.com Subject: Re: [Freeipa-users] Does Solaris 11 work as client to IPA server? On 12/20/2012 07:13 PM, Johan Petersson wrote: Hi, Was your example of a new DUAProfile ever added to Fedora or RHEL? If so i can't find any reference to it or a fix of the documentation. If not, is there a way to add it myself for my configuration? There is always the manual way otherwise i guess. Are Red Hat going to support RHEL clients only in IPA Server? We will have several Linux flavours, Solaris, Windows 7/8 + Server 2012 and Mac OS X so the answer to that question is kind of interesting. :) Regards, Johan Johan, Would you mind summarizing your Solaris 11 experience in a step by step procedure so that we can add it to wiki or Fedora docs? Thanks Dmitri From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Johan Petersson [johan.peters...@sscspace.com] Sent: Thursday, December 20, 2012 19:03 To: Sigbjorn Lie Cc: freeipa-users@redhat.com
Re: [Freeipa-users] Joining Fedora 18 (FreeIPA 3.1.0) to CentOS 6.3 (FreeIPA 2.1.90rc1)
On 12/23/2012 03:32 PM, Michael B. Trausch wrote: Whoops. Let's try this again, I failed to post it correctly the first time. Hrm. It'd seem I overlooked something... [776940.813555] ipa-getkeytab[28840]: segfault at 0 ip 7fa38cda61dc sp 7fffbdf1bce0 error 6 in libgssapiv2.so.2.0.25[7fa38cda3000+7000] I guess I better get a bug filed if there isn't one already. I assume that the bug should go to Fedora, and not the FreeIPA project, would that be correct? Thanks and Happy Holidays! Mike ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users