On 4.9.2013 20:23, Bret Wortman wrote:
...and I tried exporting the DNS data but ended up with a bunch of files
that looked liket his:
# cat foo.net.db
; <<>> DiG 9.9.3-rl.156.01.P1-RedHat-9.9.3-3.P1.fc18 <<>> +onesoa -t AXFR
;; global options: +cmd
; Transfer failed.
The logs showed:
<timestamp> ipamaster named: client 220.127.116.11#39992 (foo.net) : zone
transfer 'foo.net/AXFR/IN' denied
You have to add IP '18.104.22.168' to the allow-transfer Address List Match.
$ ipa dnszone-mod --allow-transfer='localhost; 22.214.171.124;'
for further details.
On Wed, Sep 4, 2013 at 1:32 PM, Simo Sorce <s...@redhat.com> wrote:
On Wed, 2013-09-04 at 09:40 -0400, Dmitri Pal wrote:
On 09/04/2013 09:26 AM, Petr Spacek wrote:
On 4.9.2013 15:04, Bret Wortman wrote:
What's the right venue for making a suggestion? In particular, I'd
toss out there that it would be really nice to be able to export, at a
minimum, DNS and user data from IPA in the form of a zone file and a
passwd/shadow file pair.
I realize there might be security implications to the latter, and
out passwords might be advisiable. And there's no easy way,
get out sudo information. But having DNS and user details would at
permit a sysadmin having major issues (like I have been for the past
weeks) to get up and running in some form, using puppet or some other
to distribute flat files with named running against a static zone
even to migrate off IPA if absolutely necessary.
for DNS you can use normal zone transfer. Just configure IPA zone to
allow zone transfer to an IP address (localhost means 'localy to IPA
server') and use standard DNS tools, e.g. dig:
$ ipa dnszone-mod example.com --allow-transfer='localhost;'
$ dig +onesoa -t AXFR example.com > /root/example.com.db
That is all you need for DNS, you have the standard zone file.
I believe that you can use SSSD (with enumeration enabled) to run
"getent passwd > /root/passwd.bck". I have no idea how it works with
shadow map/password. Try to ask sssd-us...@lists.fedorahosted.org.
And to add to it:
IPA does not keep password in clear or the hashes that are used in
passwd and shadow files for security reasons so it can't generate these
files as you suggest.
We do have hashes, the default is SHA256, it is stored in userPassword
and is used to validate LDAP binds, however we never let it out of LDAP,
neither SSSD not the integrate NIS server expose the password hash to
clients. You need Directory Manager privileges to read it.
Freeipa-users mailing list