Microsoft Active Directory integration
This is a broad topic with many possibilities.. Here is a quick list of my current thinking.
- Tie information about delegated domains into ONA from an AD domain.
- we could use LDAP to lookup up data. some info about this is here: http://codeidol.com/active-directory/active-directory/DNS-and-DHCP/Introduction/
- could use a simple axfr of the AD domain. This is the current direction as it is simple and easy and likely to be possible in most situations. I would likely use net_dns2 pear module to do the transfer into a local table. I would watch the SOA to do updates and or use the caching that net_dns2 has.
- Tie information about DHCP that is managed within a MS server. I've not explored how or what this would be but it is likely to be useful in the same way I'm exploring DHCPLEASEQUERY to pull in pool data from an ISC DHCP server.
Something else to look at is Microsoft's netsh and powershell scripting languages. Both have ways to dump info from DNS and DHCP as well as write to them.
good call.. I've not thought of those options (or didnt even really know about them).. one goal would be the ability to remotely utilize them.. say from the ONA install
was thinking about this more.. just capturing thoughts:
- do a zone transfer.. could use axfr-get (sort -u) from djbdns or net_dns2 or similar
- watch the serial number of the zone to detect a change.. this can be stored in the AD zone in ONA for reference
- start with just A records for now.
- convert IP to numeric, look for it in interfaces table. log/track somehow if you dont find it.
- look up FQDN and see if there is a DNS name already in the system. skip (or are there any updates we care about?)
- if we find an IP interface and no existing DNS entry, then add it in. maybe use notes or something to track it was loaded from AD on some timestamp
- how might we determine entries in ONA that should be removed?
another approach would be to compare it more at a DNS level.. basically query up a tinydns zone build, do the zone xfer.. then sort/diff them together and see what falls out.. process that list.
Also probably should have some sort of flag on the domain that says it is an AD delegation.. maybe we dont care if it is AD at all????? or we just flag it as a domain that needs to be synced from another source.
Should be able to process other record types after the A records are loaded?
The reason loading the data into ONA is nice is that it easily allows for searching and tie-in to existing hosts.. basically if I want to manage a host in ONA so I get mac-IP for DHCP, then I also need to have a proper name for it to use. This allows me to put it in ONA first, then once it is deployed and joins the domain the check can come back around and ensure it remains accurate. Plus find anything that does not match up.