Bug #13237
closed
ERROR_ACCESS_DENIED when deleting DNS A record (dns_dnscmd plugin)
Description
Record creation works just fine but when you try to delete the host you will get access denied and HTTP 404 back from the smart proxy.
dnscmd.exe DC.example.com /RecordDelete example.com record.example.com. A /f
Command failed: ERROR_ACCESS_DENIED 5 0x5
It looks like it's necessary to include RRData (e.g. IP address in this case) when deleting A record.
Syntax: dnscmd ServerName /recorddelete ZoneName NodeName RRType RRData[/f]
Quick hint to fix it:
\modules\dns_dnscmd\dns_dnscmd_main.rb
38c38
< cmd = "/RecordDelete #{zone} #{fqdn}. A /f"
---
cmd = "/RecordDelete #{zone} #{fqdn}. A #{ip} /f"
DNS service is running on W2k12R2
Updated by Alex Fisher over 8 years ago
I've hit this too.
I don't think the fix is quite as trivial as suggested though.
From what I can see, the foreman smart-proxy API for deleting DNS A records doesn't support the IP address being sent as well as the fqdn.
https://github.com/theforeman/smart-proxy/blob/develop/modules/dns/dns_api.rb#L43
I don't think it should be too hard to use dnscmd /EnumRecords to build a list, (of most likely 1), specific entries that need to be deleted though. I'll try hacking on a patch...
Meanwhile, does anybody know why the current solution isn't working for some of us? All dnscmd documentation I've come across certainly suggests that specifying the RRData field is optional.
Updated by The Foreman Bot over 8 years ago
- Status changed from New to Ready For Testing
- Pull request https://github.com/theforeman/smart-proxy/pull/410 added
Updated by Anonymous over 8 years ago
Would be helpful to see the contents of event log when this error is reported...
Updated by Alex Fisher over 8 years ago
It's been a while, but I've finally been able to get some time with a domain admin to investigate this further. Even after much fiddling we weren't able to get anything useful logged, but we did discover the following...
The only way to delete records (without specifying the RRData option) was to (temporarily) give the service account user 'Full Control' privileges on the zone. No other combination of privileges worked, (including ticking everything other than 'full control'). This might be acceptable to some, but I won't be allowed to run with the account configured this way (eg it can delete the whole zone in a single click). Some organisations might be prepared to grant the user these elevated privileges, but I imagine many won't.
Updated by Alex Fisher about 8 years ago
- Status changed from Ready For Testing to Closed
- % Done changed from 0 to 100
Applied in changeset 67c1cc836418583d85b7782b1ceef3ac554e0abd.
Updated by Dominic Cleal about 8 years ago
- Assignee set to Alex Fisher
- Translation missing: en.field_release set to 189