So I know that there are extensions to SLAAC in the works to enable DNS discovery via RAs (RFC 6106). But what was the original intent? How did the IPv6 designers envision things working without DNS? Why did multicast DNS get dropped from Windows? I can find lots of info on SLAAC, its lack of DNS support, and the SLAAC/DHCPv6 debate (and the proposed, and yet unsupported, extension) but no discussion of the original rationale.
We have a pair of ASA 5510s (8.4.3) on which we use LDAP authentication for VPN and SSH access. On all of our Catalyst switches, which use RADIUS, we're able to set the shell:priv-lvl to 15 in the RADIUS config (2008R2 NPS). However, the best I can find on the ASAs, including in all the Cisco docs, is to abuse some other field, such as title or company, by sticking "15" into it and mapping that to the Privilege-Level RADIUS attribute in the AAA config. What I really want to do is assign anyone in an AD group L15 privs on the ASAs without having to type in a shared password. Anyone know if there's a way to do this?
We're a small company with a 2008R2 domain on which we have a file server with several shared volumes. We have a number of IT staff in the domain administrators role, because effectively we're all on call 24x7. However, it has recently become an issue of company policy that there are certain folders or files (salary data, performance reviews, accounting info) that should be confidential, including from IT staff. This also includes the data on backups (tape and disk).
Things that have occurred to us so far:
*EFS - but we'd have to set up a PKI, which is a bit overkill for our company size
*TrueCrypt - but this kills concurrent access and search-ability
*Remove Domain Admins from the ACLs - but this is extremely easy (one click) to bypass
*Dropping use of the Domain Admins group, and delegating permissions more explicitly - but again this is a bit overkill, and we want to reduce the need for shared accounts (e.g., MYDOMAIN\Administrator) as possible for audit reasons
I'm sure this is not a novel problem, and am curious how other people with this sort of requirement have handled it? Are there any options that we haven't already considered?
Thanks!
We have a network on which we're setting up a test IPv6 deployment. Here's the layout:
Win2008R2 DHCP VM and Debian Squeeze radvd VM -> vSphere 5.0 vSwitch -(Trunk)-> Catalyst 2960G -(Trunk)-> Catalyst 2960G -> Win7 Laptop
SLAAC works fine, but as soon as I turn off autonomous mode for the prefix, I can see that DHCPv6 is not working properly (the client doesn't get any of the scope options from the Win 2008R2 DHCP Server). Running Wireshark on the client shows that DHCPv6 solicitations are being sent, as expected. Running Wireshark on the DHCP server shows that the packets aren't making it across the network.
My question: I know that DHCPv6 is multicast-based. Could the Catalysts or vSwitches be eating these solicitations? If so - how do I rectify that?
I've locked myself out of an APC 9617 management card. Trying to figure out how to reset the password, or even the card to factory defaults. All the documentation I can find says to connect to the serial interface on the 9617 and initiate a reset with the pin-hole button. However, the card has no serial interface. Tried connecting a serial cable to the UPS itself, and somehow managed to send a shutdown command to it (so much for our network stack).
So - has anyone done a reset on a 9617?
I have a two-site domain (call them Local and Remote). Site Local has our main IT infrastructure, including two Active Directory Domain Controllers (2008R2). We're trying to set up an RODC at site Remote, which for the most part works just fine. Everything is replicated, password replication follows the policy, the remote DC answers queries - so all good. Except that machines in site Local, when querying the AD, are referred to site Remote. If I do a tcpdump, I see the LDAP query hit both of the Local DCs, and then go on to the Remote RODC.
I've ensured that all of the subnets on both ends are configured in the Site and Services snap-in, and that the DCs are both in their respective sites. According to my research, that should be all that's required for the clients to query the closest DC. Have I missed a step?