Thursday, 30 July 2015

Android devices not showing in Windows (MTP)

This has bugged me for a few generations of devices now and stumped me a few times...

Nexus 4, HTC One and Nexus 6 that I recall have had similar quirks - especially with later Windows versions (i.e. 8 and later)!

I've moved files off my Nexus 6 a few times since I got it late last year, and this time... it decides to not appear - but I could see it in device manager as an ADB device...

Found this article which explains a simple fix:

Basically device manager > Android ADB device > update driver > let me choose > USB MTP device > fixed

Thursday, 2 April 2015

Sites, Services and Domain Controllers

One of the things that baffles me is how little Sites and Services is understood and oddly implemented around the place.

I'd recommend giving this a good thorough read through, twice, if you administer AD anywhere - it's one of my most frequently shared links when someone starts talking to me for a couple of reasons of which I'll include a brief summery below...

Sites, Sites, Everywhere...

1) Automatic Site Coverage

Every domain controller in the forest follows this procedure:

  1. Build a list of target sites — sites that have no domain controllers for this domain (the domain of the current domain controller).
  2. Build a list of candidate sites — sites that have domain controllers for this domain.
  3. For every target site, follow these steps:
  1. Build a list of candidate sites of which this domain is a member. (If none, do nothing.)
  2. Of these, build a list of sites that have the lowest site link cost to the target site. (If none, do nothing.)
  3. If more than one, break ties (reduce this list to one candidate site) by choosing the site with the largest number of domain controllers.
  4. If more than one, break ties by choosing the site that is first alphabetically.
  5. Register target-site-specific SRV records for the domain controllers for this domain in the selected site.

2) DCLocator

  1. Client does a DNS search for DC’s in _LDAP._TCP.dc._msdcs.domainname
  2. DNS server returns list of DC’s.
  3. Client sends an LDAP ping to a DC asking for the site it is in based on the clients IP address (IP address ONLY! The client’s subnet is NOT known to the DC).
  4. DC returns…
    a. The client’s site or the site that’s associated with the subnet that most matches the client’s IP (determined by comparing just the client’s IP to the subnet-to-site table Netlogon builds at startup).
    b. The site that the current domain controller is in.
    c. A flag (DSClosestFlag=0 or 1) that indicates if the current DC is in the site closest to the client.
  5. The client decides whether to use the current DC or to look for a closer option.
    a. Client uses the current DC if it’s in the client’s site or in the site closest to the client as indicated by DSClosestFlag reported by the DC.
    b. If DSClosestFlag indicates the current DC is not the closest, the client does a site specific DNS query to: _LDAP._TCP.sitename._sites.domainname (_LDAP or whatever service you happen to be looking for) and uses a returned domain controller.
3) DNS
The information above DCLocator about DNS records

After understanding all this - designing and spotting potential issues may becomes easier...

Tuesday, 6 January 2015

RODC Deployed and not authenticating local users

I've seen this a few times so I am going to quickly write something about it.
Read Only Domain Controllers (RODCs) are deployed and yet the users that you would expect to authenticate to it, are going to a different domain controller (a normal DC).

Have you configured Password Replication Policy on the RODC?
Without configuring this they are not doing a lot... (apart from DNS etc. obviously)

I have seen this a few times where someone has deployed an RODC and not followed through the configuration - generally because they understand the concept but not how to put it into practice.

To check the config - go to the DC in Active Directory Users and Computers > Properties > Password Replication Policy

The standard groups are shown and I'd hope a custom one set to "allow"
Standard Groups:
Account Operators - Deny
Administrators - Deny
Allowed RODC Password Replication Group - Allow
Backup Operators - Deny
Denied RODC Password Replication Group - Deny
Server Operators - Deny

Basically, by default - there's nothing allowed!

One of the points of an RODC is that it limits what is hit if its stolen.

If you add authenticated users in there –great, it’ll cache everyone's passwords locally (apart from those denied)  If its stolen you've lost the lot… there’s an option when removing an RODC (by force) that says “do you want to force reset all the cached passwords”

That’d cause massive headaches for those users if authenticated users is in there as every single account would be prompted to change password, and if you have a stray service account in there. uhoh.

Allowed RODC Password Replication Group by default contains nothing… you can populate this, but you will distribute this around all RODCs - this may not be desirable.

I created an admin group in there for delegated RODC admins only, as they may be done by a single infrastructure team (using nested groups).
Then separated each RODC with its own custom resource group, in which there were computer groups and user groups for users/computers and servers.

In the password delegation tab on the RODC:

in the RG-RODC-Cache group:

Any users/workstations/servers added to the above groups (split up for ease of delegation between users/servers as may be done by different teams) will be able to authenticate to the RODC as their password is cached. Any others will go to the RW DCs.

Some screenshots would be useful here, but I don't have time to add them at the moment - I may come back and add them later.