lightxx's questions

So, as the title says, I setup a isc-dhcp-server for DHCPv6, which is working as long as UFW is disabled.

Once enabled, though I have all the necessary rules in place, and UFW is enabled for v6, it stops working.

My rules are:

xxx@deadpool:/etc/ufw# grep '546\|547' *
after6.rules:-A ufw6-after-input -p udp --dport 546 -j ufw6-skip-to-policy-input
after6.rules:-A ufw6-after-input -p udp --dport 547 -j ufw6-skip-to-policy-input    
before6.rules:-A ufw6-before-input -p udp -s fe80::/10 --sport 547 -d fe80::/10 --dport 546 -j ACCEPT

I found two related but fixed bugs on launchpad: https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/947416 https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1007326

Any ideas?

So, we're self hosting our DNS forward and reverse zones, and are using our upstream - ISP as slaves.

Now, we've got a bunch of zones that have an identical SOA record.

I want to use an $INCLUDE for this SOA record, because it is completely redundant information, except for the serial.

Now the problem is, the serial would be identical for all zones, and whenever I change a single zone, I would increment the serial for all zones, thus triggering an unnecessary retransfer of all zones to the slaves.

Now, this is not much data, some KiB at most. Still, the question is, is this considered bad practice, given that the retransfer is unnecessary?

Any opinions on that? Should I just go for it?

So, we recently got our /48 prefix from our LIR, and started small-scale deploying it in a lab.

What struck me as odd is that sites like http://ipv6-test.com/ insist that you allow incoming ICMP Echo requests. I understand why you should allow ICMPv6 outgoing, but incoming? Even if it's just a ping?

So, my question is: Aside from possible DDoS attacks utilizing ICMP, are there any drawbacks in allowing incoming ICMP echo requests?

I read RFC4890 ( https://www.ietf.org/rfc/rfc4890.txt ) but couldn't find a definite answer there.

A.5. ICMPv6 Echo Request and Echo Response

suggests that

It is not thought that there is a significant risk from scanning attacks on a well-designed IPv6 network (see Section 3.2), and so connectivity checks should be allowed by default.

Is this point still valid, given the RFC is almost 10 years old? Also, the RFC does not differentiate between outgoing and incoming directions.

I always felt the recommendation for v4 was to block ICMP at the gateway, but then again, v6 heavily relies on ICMP.

So, any suggestions?

So I successfully deployed Skype for Business 2015, registered our PIC at https://pic.lync.com, successfully ran Microsoft Remote Connectivity Analyzer at https://testconnectivity.microsoft.com/ (says it tests only Lync but works for SfB as well).

An internal Skype for Business Client can successfully search the public Skype directory and add Skype accounts. However, the 'We've sent a contact request." part of the screenshot below never happens. In fact, the Skype user never gets a contact request.

Also, Skype Users can't search for our federated Skype for Business accounts in the public Skype Directory.

So obviously I must have missed something while deploying SfB, but I can't figure out what. I double and tripple-checked every deployment guide I could come up with, nothing. Double-checked our firewall ACLs as well, all good.

Any ideas?

I successfully enabled auto-enrollment for client computer certificates within our Active Directory domain.

However, I want to include additional details in the auto-enrolled certificate such as the organizational unit (OU) the client computer is located in. I can do this just fine by manually creating an CSR and submitting it to our CA, however, I wan't to use auto-enrollment.

I can't, for the heck of it, find a way on how to include additional information in auto-enrolled certificates. Is there any way to do this?

I need to campus-wide disable the Microsoft LLDP Protocol Driver using Group Policy / SCCM / or any other means of centralized management, because I've written my own LLDP broadcast service I plan on using instead of the crippled MS implementation.

I tried googling but wasn't able to come up with a working solution.

EDIT: I took two registry snapshots and compared them, the three keys that change when the checkbox is toggled are located under

HKLM\SYSTEM\CurrentControlSet\Services\MsLldp\Linkage

The keys are Bind / Route / Export

The problem is when these keys are deleted / emptied, the checkbox turns itself back on.