Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Recent Posts

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

[Aside] Links to DFSR, Profile Data, etc.

Been reading quite a bit about user profiles and stuff lately. I’ve always imagined profiles as this blob of user settings + data under the C:\Users\<username> location. And every time we need to reset a profile there’s this arduous task of backing up the user data too and restoring it. Silly.

But turns out it’s just easier to use folder redirection and redirect all your data folders to a common place. Advantage of this is that roaming profile users can login any place and have the latest up-to-date data. None of the hassle of requiring a logoff-login for the profile to sync etc.

TIL: Windows 10 goes back to adding a .v5 suffix to profiles

So, back in the Windows 7/ Server 2008 era if you had a roaming profile it was always suffixed with a .v2 extension. So if you username was “rakhesh” and your profile path in AD was “\\someservers\profiles“, the actual path created there would be “\\someservers\profiles\rakhesh.v2“. This is because Windows 7/ Server 2008 had a different profile format to Windows XP/ Server 2003 and prior, so Microsoft decided to tack on this extension so there’s no corruption. Neat idea!

But with Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2 there was no similar extension. So if you started using roaming profiles with these OSes, and you had a mixed environment, you were in for some trouble. Everything would write to the .v2 profile.

Turns out you can apply a hotfix for Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2, and then create a new registry value UseProfilePathExtensionVersion (of data 1) under HKLM\System\CurrentControlset\Services\ProfSvc\Parameters and this will cause these two OSes to append a .v3 and .v4 suffix respectively to the roaming profiles. Nice!

With Windows 10/ Server 2016 though, the OS goes back to the old behavior of adding a .v5 extension. So no need for any hotfix or registry key changes. Nice!

As an FYI to myself here’s two alternative approaches to Windows 8/ Server 2012 and Windows 8.1/ Server 2012 R2 profile handling if one didn’t want to go the hotfix + registry key change route: this one’s from Microsoft, and this one’s something I found while Googling. I prefer the latter.

Update: To keep things interesting (via) –

  • Windows 10 build 1511 and older use v5 profiles. (These are builds 1507 and 1511 – aka Threshold 1 and Threshold 2).
  • Windows 10 build 1607 and newer use v6 profiles. (Build 1607 is also known as Redstone 1. The next one, build 1703 is known as Redstone 2, and so on).
  • Windows Server 2016 uses a v6 profile.

[Aside] Domain Controller locator

A while ago I was reading up on the Domain Controller process to confirm some stuff before changes I was making at work. Found a couple of good links, still got them open in my browser but before closing them out I thought I should paste them here as a reference to myself. I know most of the info, but occasionally you forget what you know or need a quick confirmation.

DFSR misconception: the hub server does not mean it is the master

Came across this Microsoft blog post by chance. To quote:

If the topology is set up for hub and spoke, and the spoke were to accidentally delete an item, this should not reflect back to the hub, correct? This should be a one way transfer. What we are seeing is our hub replicates out to the spokes perfectly, but if the spoke deletes an item, the item is then deleted from our hub share. It seems to be acting like a full mesh topology, but it was originally set up at as hub and spoke.

The behavior the customer describes is by design. Because DFS Replication is a multimaster replication engine, any change made on any spoke is replicated back to the hub and to the other spokes. To prevent changes from occurring on spokes, we recommend using shared folder permissions.

I too had always thought a hub-spoke design means the hub is the master server. But now I realize how wrong I was. Basically a hub-spoke or full mesh topology only determines the sync path – it does not denote which server is the master and which servers are slaves. DFSR, like AD, has no master or slave.

In a hub-spoke replication topology, two spoke servers will sync with each other via the hub server – that’s all! Neither server is “inferior” to the master in any way.

Two nice quotes from “Wakefield”

Saw “Wakefield” (movie) just now. Loved it. Not at all what I had expected from the synopsis. That sounded like a creepy/ stalker sort of movie, but the actual movie was amazing. Two nice quotes from it.

This is from a point in the movie where the main character (Howard) realizes how he has escaped from a prison of his own making (his past behavior and insecurities):

If anything, I’ve come into my senses fully.

My god, I can see it so clearly.

I’ve constructed the whole thing.

The jealousy …

… the resentment …

…the selfish urgency.

Howard is victim.

Howard is persecutor.

Howard has mastered the world.

That was my prison. That’s what I’ve escaped.

Leaving me where now?

An outcast of cosmos.

And this is just a line he says sometime as he is watching his wife.

I just want you to want me as much as I want you.

Good stuff!

[Aside] Various SharePoint links

Been dabbling in a bit of SharePoint at work, here’s some links I came across and want to put here as a reference Future Rakhesh:

Notes on ADFS

I have been trying to read on ADFS nowadays. It’s my new area of interest! :) Wrote a document at work sort of explaining it to others, so here’s bits and pieces from that.

What does Active Directory Federation Services (ADFS) do?

Typically when you visit a website you’d need to login to that website with a username/ password stored on their servers, and then the website will give you access to whatever you are authorized to. The website does two things basically – one, it verifies your identity; and two, it grants you access to resources.

It makes sense for the website to control access, as these are resources with the website. But there’s no need for the website to control identity too. There’s really no need for everyone who needs access to a website to have user accounts and passwords stored on that website. The two steps – identity and access control – can be decoupled. That’s what ADFS lets us do.

With ADFS in place, a website trusts someone else to verify the identity of users. The website itself is only concerned with access control. Thus, for example, a website could have trusts with (say) Microsoft, Google, Contoso, etc. and if a user is able to successfully authenticate with any of these services and let the website know so, they are granted access. The website itself doesn’t receive the username or password. All it receives are “claims” from a user.

What are Claims?

A claim is a statement about “something”. Example: my username is ___, my email address is ___, my XYZ attribute is ___, my phone number is ____, etc.

When a website trusts our ADFS for federation, users authenticate against the ADFS server (which in turn uses AD or some other pool to authenticate users) and passes a set of claims to the website. Thus the website has no info on the (internal) AD username, password, etc. All the website sees are the claims, using which it can decide what to do with the user.

Claims are per trust. Multiple applications can use the same trust, or you could have a trust per application (latter more likely).

All the claims pertaining to a user are packaged together into a secure token.

What is a Secure Token?

A secure token is a signed package containing claims. It is what an ADFS server sends to a website – basically a list of claims, signed with the token signing certificate of the ADFS server. We would have sent the public key part of this certificate to the website while setting up the trust with them; thus the website can verify our signature and know the tokens came from us.

Relying Party (RP) / Service Provider (SP)

Refers to the website/ service who is relying on us. They trust us to verify the identity of our users and have allowed access for our users to their services.

I keep saying “website” above, but really I should have been more generic and said Relying Party. A Relying Party is not limited to a website, though that’s how we commonly encounter it.

Note: Relying Party is the Microsoft terminology.

ADFS cannot be used for access to the following:

  • File shares or print servers
  • Active Directory resources
  • Exchange (O365 excepted)
  • Connect to servers using RDP
  • Authenticate to “older” web applications (it needs to be claims aware)

A Relying Party can be another ADFS server too. Thus you could have a setup where a Replying Party trusts an ADFS service (who is the Claims Provider in this relationship), and the ADFS service in turn trusts a bunch of other ADFS servers depending on (say) the user’s location (so the trusting ADFS service is a Relying Party in this relationship).

Claims Provider (CP) / Identity Provider (IdP)

The service that actually validates users and then issues tokens. ADFS, basically.

Note: Claims Party is the Microsoft terminology.

Secure Token Service (STS)

The service within ADFS that accepts requests and creates and issues security tokens containing claims.

Relying Party Trust

Refers to the trust between a Relying Party and Identity Provider. Tokens from the Identity Provider will be signed with the Identity Provider’s token signing key – so the Relying Party knows it is authentic. Similarly requests from the Relying Party will be signed with their certificate (which we can import on our end when setting up the trust).

Examples of setting up Relying Party Trusts: 1 and 2.

Web Application Proxy (WAP)

Access to an ADFS server over the Internet is via a Web Application Proxy. This is a role in Server 2012 and above – think of it as a reverse proxy for ADFS. The ADFS server is within the network; the WAP server is on the DMZ and exposed to the Internet (at least port 443). The WAP server doesn’t need to be domain joined. All it has is a reference to the ADFS server – either via DNS, or even just a hosts file entry. The WAP server too contains the public certificates of the ADFS server.

Miscellaneous

  • ADFS Federation Metadata – this is a cool link that is published by the ADFS server (unless we have disabled it). It is https://<your-adfs-fqdn>/FederationMetadata/2007-06/FederationMetadata.xml and contains all the info required by a Replying Party to add the ADFS server as a Claims Provider.
    • This also includes Base64 encoded versions of the token signing certificate and token decrypting certificates.
  • SAML Entity ID – not sure of the significance of this yet, but this too can be found in the Federation Metadata file. It is usually of the form http://<your-adfs-fqdn>/adfs/services/trust and is required by the Relying Party to setup a trust to the ADFS server.
  • SAML endpoint URL – this is the URL where users are sent to for authentication. Usually of the form http://<your-adfs-fqdn>/adfs/ls.  This information too can be found in the Federation Metadata file.
  • Link to my post on ADFS Certificates.

Certificate stuff (as a note to myself)

Helping out a bit with the CA at work, so just putting these down here so I don’t forget later.

For managing user certificates: certmgr.msc.

For managing computer certificates: certlm.msc.

Using CA Web enrollment pages and SAN attributes requires EDITF_ATTRIBUTESUBJECTALTNAME2 to be enabled on your CA.

Enable it thus:

When making a request, in the attributes field enter the following for the SANs: san:dns=corpdc1.fabrikam.com&dns=ldap.fabrikam.com.

 

Find users connected to a NetScaler gateway

Wanted to find out if a certain end-user had connected to our NetScaler gateway. Couldn’t figure out how. (And initially I went the long route of looking at the /tmp/aaadebug.log file – not really needed here!)

It’s easy. Login to the NetScaler device. Click on “NetScaler Gateway” in left pane. On the right you will find “Active user sessions” and “ICA Connections”. The former shows users who have authenticated against the gateway, and the latter is those who have an ICA connection open through the gateway. The lists could be different as a user might have timed out on the gateway but still have an ICA connection open. 

Via CLI the former is show aaa session. The latter is show vpn icaConnection. The latter will show connects to the VDA (port 2598 usually). 

Event ID 1046 – DHCP server says it is not authorized even though it is authorized!

This problem ate my head for the past 2 days and wasted a lot of time. For such a simple issue it drove me quite mad.

Built a bunch of DCs for our branch offices. One of them gave trouble with the DHCP server. I authorized it successfully, but the service kept complaining that it wasn’t authorized. Event ID 1046.

The DHCP/BINL service on the local machine, belonging to the Windows Administrative domain mydomain.dom, has determined that it is not authorized to start.  It has stopped servicing clients.  The following are some possible reasons for this: 

This machine is part of a directory service enterprise and is not authorized in the same domain.  (See help on the DHCP Service Management Tool for additional information). 

This machine cannot reach its directory service enterprise and it has encountered another DHCP service on the network belonging to a directory service enterprise on which the local machine is not authorized. 

Some unexpected network error occurred.

Did the obvious ones like reboot server :p and restart service :) and un-authorize and re-authorize the server (no errors either time). Also went ahead and removed the role itself and added back. Nothing helped!

Found a helpful post finally that pointed me in the right direction.

  1. I un-authorized the DHCP server.
  2. Opened up AD Sites and Services. 
  3. Browsed to the Services section (which can be enabled from the View menu if not already visible). 
  4. Browsed to the NetServices section within this. 
  5. On the right pane I had an entry for the IP address for the DHCP server I was trying to authorize. Not an entry by name, but by IP. Dunno why. (All other entries were by name, so I am guessing this is a leftover or a mistake by someone in the past). 
  6. I deleted this entry. 
  7. Waited a while, and then authorized the server. 
  8. No errors now!

Screenshot of the offending entry just for the heck of it (the blacked out part was an IP address):

Alternatively one can open ADSI Edit and go to CN=NetServices,CN=Services,CN=Configuration,DC=myDomain,DC=dom. Then delete the entry (as above) from there. 

What’s odd in my case is that the IP that I deleted was assigned to the DHCP server I wanted to authorize. Am guessing the CNF (short for conflict?) following by the GUID indicates some issue.

[Aside] Various Citrix links

Busy with a lot of Citrix and NetScaler work recently. Want to put the various links I came across someplace. 

Was also looking into why Citrix Receiver wasn’t creating shortcuts for our published apps even though we had ticked it in in Citrix Studio. The trick was to mark the application as a Favorite in Receiver and the shortcut would be created. Here’s some links I had found while reading on this:

Script to run esxcli unmap on all datastores attached to an ESXi host

It’s a good idea to periodically run the UNMAP command on all your thin-provisioned LUNs. This allows the storage system to reclaim deleted blocks. (What is SCSI UNMAP?)

The format of the command is:

I wanted to make a script to run this on all attached datastores so here’s what I came up with:

The esxcli storage filesystem list command outputs a list of datastores attached to the system. The second column is what I am interested in, so that’s what awk takes care for me. I don’t want to target any local datastores, so I use grep to filter out  the ones I am interested in. 

Next step would be to add this to a cron job. Got to follow the instructions here, it looks like.