- #ENABLE DNS UPDATES FOR MAC CLIENT WINDOWS SERVER DHCP UPDATE#
- #ENABLE DNS UPDATES FOR MAC CLIENT WINDOWS SERVER DHCP REGISTRATION#
The first of the two scripts I used as reference had some nice logic to check if it was on a domain or not, and that might help if you are trying to avoid registrations when you are off network. I haven't included any logic to figure out which interface you want to pull the IP from, but you can put any logic you like in to generate $interface. Kinit -k -t /etc/krb5.keytab $adcomputernm nsupdate -g $TMPDIR/nsupdate This leaves any existing Kerbcredentials untouched. # the command has run cleaning things up. # By running the command via kinit the credentials cache created by kinit is destroyed after # Authenticate kerberos and run nsupdate using kerberos authentication and our command file. #echo server > $TMPDIR/nsupdateĮcho "update delete $ A" > $TMPDIR/nsupdateĮcho "update add $ $recordTTL A $ipaddr" > $TMPDIR/nsupdate # uncomment the first line to specify a DNS server otherwise the machines default will be used. # make double sure that temp file isn't there Ipaddr=`/sbin/ifconfig $interface | awk '/inet / '`
# the record TTL is set in seconds 3600 is 1 hour, 1800 half and hour etc. # get some information (we're assuming the interface we want to register is en0) # for this reason it will need to run as _root_ to be able to read /etc/krb5.keytab
#ENABLE DNS UPDATES FOR MAC CLIENT WINDOWS SERVER DHCP UPDATE#
# uses the computers own kerberos credentials from the keytab to authenticate a DNS update I've borrowed heavily form a couple of other scripts on JAMFnation which I'll link after the script.
#ENABLE DNS UPDATES FOR MAC CLIENT WINDOWS SERVER DHCP REGISTRATION#
In any case, if you want to try forcing a DNS update in a manner that is not dependent on having hardwired passwords I came up with a hack that you can trigger of cron or suchlike, and also run at the cli to test if the registration work when you are driving them rather than waiting for MacOS. If you can get access ot the AD DNS snap in it likely worth investigating and using the effective permission tool to verify that the computer account for your AD bound Macs do indeed have the ability to create A records in the zone. If your DNS admin has changed the ACLs on the zone, you may well find that an admin user can make records but computer accounts can't, or computers in a certain group can or any number of possible approaches. Under normal operation when a computer updates it's record it is authentication as its own hostname$ AD computer account, this is as a result of the zone having a ACL on it allowing authenticated users to create child items (not having delete permission should be preventing anyone overwriting or deleting anything that they didn't create).
creating a new record will likely work for any authenticated user, but it will need to be that suer or an admin who updates that record afterwards. In my testing this only worked to update an existing record when this was an administrative user, specifically one with the permission allowing it to make a DNS update, my standard user account didn't have this permission and as expected the update failed. I presume when you do this you are using whatever principal you have authenticated into your credential cache when you run the command. One thing that its likely worth checking in a scenation you have described is the ACLs on the AD DNS zone/s.ĪD DNS defaults (IIRC) to only allowing authenticated updates, which should be fine for an AD bound Mac, and it sounds like authenticated DNS updates are working when you use the -g flag on nsupdate. Although this is not quite as dramatically terrible as your issue where things are not working at all. My current issue is that I have some Macs which are sometimes seemingly stopping updating their A records, which leads to scavenging deleting them, which is very annoying. You can, and likely should use something like dsconfigad -restrictDDNS to specific which interface/s you wish to register their IPs against the machines hostname, but under "normal" circumstances it should just work. Macs with windows DNS should start registering dynamic DNS updates once they are bound. It's been a good few years since your post, but as I'm looking at a similar-ish issue and had a partial answer to your question I thought it might be worth sharing the fruits of my evening re-acquainting myself with DNS OSX and Kerberos.
0 kommentar(er)
