(2011-09-14) Kerberos Authentication Over An External Trust – Is It Possible? (Part 6)

In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server.

In PART 3 I showed the usage of Kerberos authN accessing the websites from another computer in the same AD forest/domain.

In PART 4 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

In PART 5 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a EXTERNAL TRUST is in place

In this, really, last post about this I will, besides showing the usage of Kerberos authN while a EXTERNAL TRUST is in place, also explain how to achieve this functionality.

-

All of you that read the first 5 blog posts about this topic AND tried to achieve this, may have failed to achieve the result that I was able to achieve. The main reason for is that I never mentioned the missing link in this. If you dug deep into it you end with the question “How does the TRUSTED domain find the TRUSTING domain that owns the service principal name?”

-

To make sure it is explained correctly so that you understand it correctly, let’s go through all of it again. With this information you will be able to try it your self!

-

Let’s start again with a FOREST TRUST and its configuration…

-

Figure 1: One-Way Forest Trust –> TRUSTED FOREST = ADCORP.LAB (Incoming) | TRUSTING FOREST = ADDMZ.LAN (Outgoing)

-

Figure 2: Name Suffix Routing Configuration On The Forest Trust For The TRUSTING FOREST

-

Figure 3: The Forest Trust Configuration On The TRUSTED Side From An Attribute Perspective

-

Figure 4: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO)

-

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
7. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
8. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
10. The user account presents the TGS to the website
11. Based upon the contents of the TGS the website allows access

REMARK: Detailed information about Kerberos authN can be found HERE.

REMARK: The information in the “msDS-TrustForestTrustInfo” attribute is build from the information within the trusting AD forest, such the “UPN-Suffixes” attribute and the “ms-DS-SPN-Suffixes” attribute on the Partitions container. Also see “Building Well-Formed msDS-TrustForestTrustInfo Messages” and “Routing name suffixes across forests”

-

So far so good!

-

Let’s continue again with an EXTERNAL TRUST and its configuration…

-

Figure 5: One-Way External Trust –> TRUSTED DOMAIN = ADCORP.LAB (Incoming) | TRUSTING DOMAIN = ADDMZ.LAN (Outgoing)

-

Figure 6: Name Suffix Routing Configuration On The External Trust For The TRUSTING FOREST. WAIT! There is None!!!

-

Figure 7: The External Trust Configuration On The TRUSTED Side From An Attribute Perspective

-

Figure 8: The Human Readable Information Stored In The “msDS-TrustForestTrustInfo” Attribute Of The Trusted Domain Object (TDO). WAIT! There is None!!!

-

So, if you take the configuration that I posted in PART 1 into account, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4).(Failure!)
7. THEREFORE, the DC in the “ADCORP.LAB” AD domain servicing the user account CANNOT issue a referral ticket to the user account for the AD domain “ADDMZ.LAN”
8. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGT for the “ADDMZ.LAN” AD domain.
9. THEREFORE, The DC in the “ADDMZ.LAN” AD domain servicing the user account CANNOT issue a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
10. THEREFORE, the user account CANNOT present the TGS to the website
11. THEREFORE, the user account cannot leverage Kerberos AuthN!
12. Because either website is configure with NEGOTIATE, the system will switch to NTLM authN.

REMARK: Detailed information about NTLM can be found HERE.

-

After you have enabled Verbose Kerberos Logging as explained in MS-KBQ262177 you will see the following in the System Event Log (DO NOT FORGET TO DISABLE IT AGAIN!)

Figure 9: Kerberos Error Message About Not Being Able To Find The SPN In The Local AD domain/forest

-

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 22:7:3.0000 9/13/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

-

So, the main reason for External Trusts NOT supporting Kerberos AuthN is because there is no routing information available to create the referral! The DCs do not have enough information for the next hop. That’s really it! If there would be a mechanism that is able to provide such required information, you would Kerberos over the external trust. What can you do about this, is the question that needs to be answered!

When you open the GPMC you will see the following settings (amongst others!)

Figure 10: GPO Settings To Configure The KDC Service On A DC

-

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Key Distribution Center (KDC) searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the KDC will search the forests in this list if it is unable to resolve a two-part SPN in the local forest. The forest search is performed by using a global catalog or name suffix hints. If a match is found, the KDC will return a referral ticket to the client for the appropriate domain.

If you disable or do not configure this policy setting, the KDC will not search the listed forests to resolve the SPN. If the KDC is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

To ensure consistent behavior, this policy setting must be supported and set identically on all domain controllers in the domain.

-

Figure 11: GPO Settings To Configure The Kerberos AuthN Protocol On Windows Computers In Common

-

Pay close attention to the GPO Setting called “Use forest search order”. The description is:

This policy setting defines the list of trusting forests that the Kerberos client searches when attempting to resolve two-part service principal names (SPNs).

If you enable this policy setting, the Kerberos client will search the forests in this list if it is unable to resolve a two-part SPN. If a match is found, the Kerberos client will request a referral ticket to the appropriate domain.

If you disable or do not configure this policy setting, the Kerberos client will not search the listed forests to resolve the SPN. If the Kerberos client is unable to resolve the SPN because the name is not found, NTLM authentication might be used.

-

The GPO Setting “Use forest search order” is therefore the mechanism that is able to provide the missing information for this to work! If you look carefully in figure 12, this will only work for W2K8R2 AD forest!

-

I will therefore use the option shown in figure 10 and configure it as shown below:

Figure 12: Configuring The GPO Setting “Use Forest Search Order” That Will Be Applied On ALL DCs (GPO Setting In Figure 10) And Applied On All Windows Computers (GPO Setting In Figure 11) In The AD Domain/Forest

REMARK: It should be enough to configure either the KDC on all W2K8R2 DCs or all Win7/W2K8R2 computers in the AD domain

-

Make sure to wait until end-to-end AD/SYSVOL Replication is complete and every DC has (re-)applied the GPO with the new GPO Setting. In this case I executed GPUPDATE /FORCE on the one and only RWDC I have in my TRUSTED AD FOREST.

-

So, if you NOW take the configuration that I posted in PART 1 into account AND the configuration shown in figure 10 and 12, the following will happen when a user from the “ADCORP.LAB” AD forest logged on to a computer also from the “ADCORP.LAB” AD forest is accessing the websites “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82” (high-level steps):

1. User account in “ADCORP.LAB” AD domain logs on to computer in “ADCORP.LAB” AD domain.
2. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a TGT for the “ADCORP.LAB” AD domain.
3. To access either website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” or “HTTP://R2FSMBSVA.ADDMZ.LAN:82”, the user account requests a TGS for either service.
4. The DC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD domain but cannot find a user account or a computer in the local AD domain that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
5. The GC in the “ADCORP.LAB” AD domain servicing the user account looks in its own AD forest but cannot find a user account or a computer in the local AD forest that has either SPN configured “HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN”. (Failure!)
6. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any local or GC located Trusted Domain Object (TDO) (in the “msDS-TrustForestTrustInfo” Attribute) and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Failure!)
7. The DC/GC in the “ADCORP.LAB” AD domain/forest servicing the user account checks for any additional routing hints as configured by the GPO Setting “Use forest search order” and checks if it can find any SPN suffix that matches the SPN suffix of the required service/SPN to be able to refer the user to (figure 4). (Success!)
8. The DC in the “ADCORP.LAB” AD domain servicing the user account issues a referral ticket to the user account for the AD domain “ADDMZ.LAN” (single AD domain in the AD forest, otherwise additional similar steps included!)
9. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGT for the “ADDMZ.LAN” AD domain.
10. The DC in the “ADDMZ.LAN” AD domain servicing the user account issues a TGS for either website that has either SPN HTTP/DELEGCONFIG.ADDMZ.LAN” or “HTTP/R2FSMBSVA.ADDMZ.LAN” configured in its service or application pool account
11. The user account presents the TGS to the website
12. Based upon the contents of the TGS the website allows access

-

BINGO!!!!! We have a winner! Kerberos AuthN over an external trust is working!

-

To prove I’m not bullshitting you, check out the following screen dumps. Pay attention to the time shown in the screen dump.

-

Figure 13: Kerberos Tickets Cached By The Client BEFORE Accessing The Websites Over An External Trust

-

Figure 14: Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.ADDMZ.LAN:81” While An External Trust Is In Place

-

Figure 15: Kerberos AuthN Is Used When Accessing The Website “HTTP://R2FSMBSVA.ADDMZ.LAN:82” While An External Trust Is In Place

-

Figure 16: Kerberos Tickets Cached By The Client AFTER Accessing The Websites Over An External Trust

Figure 17: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/DELEGCONFIG.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:11:14.0000 9/14/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/delegconfig.addmz.lan
Target Name: HTTP/delegconfig.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

-

Figure 18: An Kerberos Error Is Still Logged In The System Event Log Because The Search For The SPN (HTTP/R2FSMBSVA.ADDMZ.LAN) In The LOCAL AD Forest Fails

A Kerberos Error Message was received:
on logon session
Client Time:
Server Time: 8:12:5.0000 9/14/2011 Z
Error Code: 0×7  KDC_ERR_S_PRINCIPAL_UNKNOWN
Extended Error:
Client Realm:
Client Name:
Server Realm: ADCORP.LAB
Server Name: HTTP/r2fsmbsva.addmz.lan
Target Name: HTTP/r2fsmbsva.addmz.lan@ADCORP.LAB
Error Text:
File: 9
Line: f09
Error Data is in record data.

-

The following question remains: “How about custom suffixes (e.g. EXTERNAL.LAN) not hosted by the AD forest “ADDMZ.LAN” by default???”. Remember that the mechanism is different. With a forest trust the information in the Trusted Domain Object (attribute “msDS-TrustForestTrustInfo”) is used that is available in the local AD forest through the GC. With an external trust that information does not exist. The KDC in the trusted AD forest or the kerberos client in the trusted AD forest searches the trusting AD forests listed in the order specified in the GPO Setting after not being able to find it in the local AD forest.

Although Microsoft has the following requirement:

• The server name in the trusting resource domain has to be the FQDN, and the domain suffix of the server name has to match the AD DS domain’s DNS FQDN

I have already shown it work if you do not use the FQDN of the server (R2FSMBSVA) but rather an alias (DELEGCONFIG.ADDMZ.LAN) which also has the same suffix as the AD forest/domain. How about an alias that has a different suffix? That also appears to work also! I created an additional website “HTTPS://DELEGCONFIG.EXTERNAL.LAN:83” on the same server. Let’s see what happens with that!

-

Figure 19: Kerberos Tickets Cached By The Client BEFORE Accessing The Website Over An External Trust

-

Figure 20 Kerberos AuthN Is Used When Accessing The Website “HTTP://DELEGCONFIG.EXTERNAL.LAN:83” While An External Trust Is In Place

-

Figure 21: Kerberos Tickets Cached By The Client AFTER Accessing The Website Over An External Trust

-

Now before you go all crazy….

• This only works when the TRUSTED/TRUSTING forest contains at least W2K8R2 DCs OR Win7/W2K8R2 computers (either one needs to be able to perform the search)
• You may have an external trust while you require Kerberos AuthN and creating a forest trust is not an option. Example: Interactive user logon over external trust fails or encounters delays
• I did not test every possible scenario! Therefore use this information for your own fun and make sure to test your own scenario! It may not apply to every possible scenario.

HAVE FUN!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 5)

In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server.

In PART 3 I showed the usage of Kerberos authN accessing the websites from another computer in the same AD forest/domain.

In PART 4 I showed the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

In this last post I will show the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a EXTERNAL TRUST is in place

-

Now, let’s try with an EXTERNAL TRUST. Detailed Configuration of the External Trust is shown below

-

According to the articles mentioned at the beginning of this post, the requirements to be able to leverage Kerberos over an External Trust are:

• The trust has to be created using the fully qualified domain name (FQDN). Kerberos referral fails if the FQDN is missing from the TDO –> I confirm the trust was setup using the DNS name of the AD domains (created individually on both sides using DNS names!)
• User name syntax is UPN and the UPN suffix is resolvable to a DC in DNS (implicit UPN) –> Not sure how to understand this
• UDP 389, UDP/TCP 88, and UDP/TCP 464 (password change requests) ports are open for the domain controllers in the user domain. –> In my environment I do have a firewall, but I confirm I created a top level rule to allow all traffic in all directions
• The server name in the trusting resource domain has to be the FQDN, and the domain suffix of the server name has to match the AD DS domain’s DNS FQDN. –> I confirm the website has the same FQDN as the server “R2FSMBSVA.ADDMZ.LAN”

-

So, let’s do this and see what happens. Not nuts, no glory!

-

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a External Trust is in place, which appears to support Kerberos as stated in the Microsoft blog and technical article!

-

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a External Trust is in place, which appears to support Kerberos as stated in the Microsoft blog and technical article!

-

You can slap me crazy, but as you can see I have got Kerberos authN working over an external trust!!! YES! Therefore: IT WORKS!!!!!!!!!!!

-

Try it yourself and enjoy!

To understand HOW it works check out PART 6

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 4)

In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server.

In PART 3 I showed the usage of Kerberos authN accessing the websites from another computer in the same AD forest/domain.

In this post I will show the usage of Kerberos authN when logged on to a computer in another AD forest/domain, while a FOREST TRUST is in place

-

In the previous posts the proof is delivered Kerberos AuthN is working against those two website. Let’s now perform the exact same test using a Forest Trust and an External Trust. Let’s first start with a FOREST TRUST.

Detailed Configuration of the Forest Trust is shown below

-

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a Forest Trust is in place, which supports Kerberos as we all know!

-

In the following picture, I’m logged on to an RWDC (“R1FSRWDC1.ADCORP.LAB”) in the AD CORP domain with the default AD CORP admin account (renamed from “ADCORP\administrator” to “ADCORP\ADM.ROOT”) that’s a domain admin within the AD CORP forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used. In addition the picture contains the proof that a Forest Trust is in place, which supports Kerberos as we all know!

-

This continues in PART 5, which is the NEXT and LAST post.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 3)

In PART 1 I explained the setup I will use.

In PART 2 I showed the usage of Kerberos authN accessing the websites on the local web server

In this post I will show the usage of Kerberos authN when logged on to another computer in the same AD forest/domain

-

In the following picture, I’m logged on locally to an RWDC (“R2FSRWDC1.ADDMZ.LAN”) in the AD DMZ domain with the default AD DMZ admin account (renamed from “ADDMZ\administrator” to “ADDMZ\ADM.ROOT”) that’s a domain admin within the AD DMZ forest/domain and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used.

-

In the following picture, I’m logged on locally to an RWDC (“R2FSRWDC1.ADDMZ.LAN”) in the AD DMZ domain with the default AD DMZ admin account (renamed from “ADDMZ\administrator” to “ADDMZ\ADM.ROOT”) that’s a domain admin within the AD DMZ forest/domain and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used.

-

This continues in PART 4, which is the NEXT post.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 2)

In PART 1 I explained the setup I will use.

In this post I will show the usage of Kerberos authN when logged on to the local application server.

-

In the following picture, I’m logged on locally to the application server (“R2FSMBSVA.ADDMZ.LAN”) in the AD DMZ domain with a custom AD DMZ user account (“ADDMZ\ADM.ADM_ADLCL_R2FSRODC5”) that’s local admin on the application server and accessing the website “DELEGCONFIG.ADDMZ.LAN”. As you can see Kerberos authN is being used.

-

In the following picture, I’m logged on locally to the application server (“R2FSMBSVA.ADDMZ.LAN”) in the AD DMZ domain with a custom AD DMZ user account (“ADDMZ\ADM.ADM_ADLCL_R2FSRODC5”) that’s local admin on the application server and accessing the website “R2FSMBSVA.ADDMZ.LAN”. As you can see Kerberos authN is being used.

-

This continues in PART 3, which is the NEXT post.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-09-07) Kerberos Authentication Over An External Trust – Is It Possible? (Part 1)

About a year or so ago I read this blog post which leads this Microsoft technical article. My first reaction was “WTF!”, because everybody has always thought, and you can read it anywhere that:

• External Trust –> NTLM AuthN only
• Forest Trust –> Kerberos AuthN and NTLM AuthN

-

I could not believe this and I had to try it out myself of course. Today was that day! So here goes!

-

Before continuing, let’s briefly discuss the infrastructure I used to test this.

• AD forest “ADCORP.LAB”
  • AD domain “ADCORP.LAB”
    • RWDC “R1FSRWDC1.ADCORP.LAB”
      
• AD forest “ADDMZ.LAN”
  • AD domain “ADDMZ.LAN”
    • RWDC “R2FSRWDC1.ADDMZ.LAN”
    • RWDC “R2FSRWDC2.ADDMZ.LAN”
    • RODC “R2FSRODC5.ADDMZ.LAN”
    • SERVER “R2FSMBSVA.ADDMZ.LAN”
      
• TEST1 –> One-way Forest Trust (as shown below)
  • Trusting AD forest = “ADDMZ.LAN”
  • Trusted AD forest = “ADCORP.LAB”
  • Forest Wide Authentication enabled

-

-

-

• TEST2 –> One-way External Trust (as shown below)
  • Trusting AD domain = “ADDMZ.LAN”
  • Trusted AD domain = “ADCORP.LAB”
  • Domain Wide Authentication enabled

-

-

-

In all cases/tests, the application server “R2FSMBSVA” hosted 5 website as shown below

The web sites are configured as follows:

• DELEGCONFIG.ADDMZ.LAN:81 (DelegConfig v2 Beta)
  • Application Pool = Kerberos AppPool
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/DELEGCONFIG.ADDMZ.LAN
  • Report option will show which authN protocol is used
• R2FSMBSVA.ADDMZ.LAN:82 (DelegConfig v2 Beta)
  • Application Pool = Kerberos AppPool
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/R2FSMBSVA.ADDMZ.LAN
  • Report option will show which authN protocol is used
• SHAREPOINT.ADDMZ.LAN (Windows Sharepoint Services configured with NTLM AuthN)
  • Application Pool = SharePoint – 80
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/SHAREPOINT.ADDMZ.LAN
• KERBAPP.ADDMZ.LAN:8080 (Windows Sharepoint Services configured for Kerberos AuthN)
  • Application Pool = SharePoint – KERBAPP.ADDMZ.LAN8080
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/KERBAPP.ADDMZ.LAN
• NTLMAPP.ADDMZ.LAN:8081 (Windows Sharepoint Services configured for NTLM AuthN)
  • Application Pool = SharePoint – NTLMAPP.ADDMZ.LAN8081
  • Application Pool Account = ADDMZ\SVC_R2_KERBAPP
  • servicePrincipalName on application pool account = HTTP/NTLMAPP.ADDMZ.LAN

-

For the tests I’m going to only use the websites:

• DELEGCONFIG.ADDMZ.LAN:81 (DelegConfig v2 Beta) –> To prove Kerberos AuthN with a Forest Trust in place
• R2FSMBSVA.ADDMZ.LAN:82 (DelegConfig v2 Beta)–> To prove Kerberos AuthN with an External Trust in place

-

To prove what type of authN is being used, I’m using DelegConfig, which you can download from here. DelegConfig is an ASP.NET application that can be used to help troubleshoot and configure IIS and Active Directory to allow Kerberos and delegating Kerberos credentials. Very handy!!!

-

To prove Kerberos AuthN IS WORKING against BOTH websites on server “R2FSMBSVA” I will target those first with a user account from the AD domain ADDMZ.LAN from a computer also within the AD domain ADDMZ.LAN

• The user account will be “ADDMZ\ADM.ADM_ADLCL_R2FSRODC5” and the computer will be “R2FSMBSVA.ADDMZ.LAN”.
• The user account will be “ADDMZ\ADM.ROOT” and the computer will be “R2FSRWDC1.ADDMZ.LAN”.

-

This continues in PART 2, which is the NEXT post.

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-06-22) Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 4)

In the past I explained in multiple posts how to restore the SYSVOL on a DC when it is replicated through either NTFRS or DFS-R. Those procedures (including screen dumps) can be found through the following links:

• Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 1)
• Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 2)
• Restoring The SYSVOL (Non-)Authoritatively When Either Using NTFRS Or DFS-R (Part 3)

In this post I will explain another method that is also available to restore the SYSVOL in an authoritative and non-authoritative way when it is replicated through DFS-R. The information posted here will be based upon the following Microsoft KB article:

• How to force an authoritative and non-authoritative synchronization for DFSR-replicated SYSVOL (like "D4/D2" for FRS)

In addition to what the KB article already mentions, this post will contain additional information such as PowerShell command lines used and screen dumps.

SYSVOL Replicated Through DFS-R – Authoritative Restore – Steps To Take

To perform an authoritative restore of the SYSVOL when using DFS-R, use the following steps (preferably on the RWDC with the PDC FSMO role!):

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE";"msDFSR-Options"=1}
  (this disables the replicated folder on this target and marks the target as primary, or in other words authoritative)
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):

Event ID 4008 in the DFS Replication Event Log appears:

Event ID 2010 in the DFS Replication Event Log appears:

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"}
  (this re-enables the replicated folder on this target)
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC1,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4602 in the DFS Replication Event Log appears:

SYSVOL Replicated Through DFS-R – Non-Authoritative Restore On RWDC – Steps To Take

To perform an authoritative restore of the SYSVOL when using DFS-R on a RWDC, use the following steps:

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE"}
  (this disables the replicated folder on this target)
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):

Event ID 4008 in the DFS Replication Event Log appears:

Event ID 2010 in the DFS Replication Event Log appears:

As an optional steps, you can specify a specific replication (sourcing) partner for the SYSVOL

• Registry Path: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesDFSRParametersSysVolsSeeding SysVols
  
  • Value name: Parent Computer
    
  • Value type: REG_SZ
    
  • Value data: <FQDN of RWDC to source from>
    

REMARK: If you do not use this method to specify the source computer, any Active Directory replication partner that has the SYSVOL replicated folder in the NORMAL state could end up being used as the source.

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"}
  (this re-enables the replicated folder on this target)
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRWDC2,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4614 in the DFS Replication Event Log appears:

Event ID 4604 in the DFS Replication Event Log appears:

SYSVOL Replicated Through DFS-R – Non-Authoritative Restore On RODC – Steps To Take

To perform an authoritative restore of the SYSVOL when using DFS-R on a RODC, use the following steps:

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="FALSE"}
  (this disables the replicated folder on this target)
  (execute this either on the RODC with sufficient permissions AND make sure you can access the Active Directory Web Service (ADWS) (tcp:9389) on the RWDC (through referral by RODC) from the RODC, OR execute this on the RWDC with sufficient access permissions)
  

You then either wait until the change that originated on an RWDC reaches the RODC, or you force inbound AD replication on the RODC. Within a DOS command prompt

• REPADMIN /SYNCALL R2FSRODC5.ADDMZ.LAN /A /d /q
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4114 in the DFS Replication Event Log appears (after the first occurrence, this event will be repeated every 5 minutes):

Event ID 4008 in the DFS Replication Event Log appears:

Event ID 2010 in the DFS Replication Event Log appears:

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Set-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -Replace @{"msDFSR-Enabled"="TRUE"}
  (this re-enables the replicated folder on this target)
  (execute this either on the RODC with sufficient permissions AND make sure you can access the Active Directory Web Service (ADWS) (tcp:9389) on the RWDC (through referral by RODC) from the RODC, OR execute this on the RWDC with sufficient access permissions)
  

You then either wait until the change that originated on an RWDC reaches the RODC, or you force inbound AD replication on the RODC. Within a DOS command prompt

• REPADMIN /SYNCALL R2FSRODC5.ADDMZ.LAN /A /d /q
  

Within a PowerShell command prompt

• Import-Module ActiveDirectory (only if not already done previously within the same PowerShell command prompt window)
  
• Get-ADObject "CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=R2FSRODC5,OU=Domain Controllers,DC=ADDMZ,DC=LAN" -properties *
  

Within a DOS command prompt

• DFSRDIAG POLLAD
  

Event ID 4614 in the DFS Replication Event Log appears:

Event ID 4604 in the DFS Replication Event Log appears:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-01-27) DC Locator – What Does "NO_CLIENT_SITE" Mean In Netlogon.log

When your DCs are logging the "NO_CLIENT_SITE" warning in the NETLOGON.LOG file, it depends on whether you can/should ignore it or not. I will explain the reason through examples by how it works and also the reasoning of why you can ignore it or not.

WHY THE "NO_CLIENT_SITE" ERROR OCCURS…..

When a computer is domain joined it knows for sure of which AD domain it is a member. A domain joined computer may or may not know the AD site it is in. Even if it thinks it knows the AD site, it may not even be in the correct AD site (e.g. because it was moved, or AD site was renamed, etc.). For the remaining part of the text I will just mention "computer" instead of domain joined computer.

Now, the following steps will be taken when the computer starts/boots and:

1. It DOES know the AD site it is in:
   
   1. It queries DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the site-wide SRV records for <SITE NAME> (By default this will be done by the RWDCs/RODCs in that AD site OR if the site has no DC, it will be done by RWDCs covering that AD site. How site coverage works can be read here – "Site Coverage Algorithm" section/paragraph.)
      
   3. The computer contacts the first DC (RWDC/RODC) (through LDAP ping, UDP:389) and does whatever it needs to do. It moves to the next DC, when the previous does not respond and if another DC exists. When there are no more site specific DCs, it performs the steps in [2]
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC/RODC will check if it can match the IP address of the computer to an AD subnet (as specific as possible).
      
      1. Assuming the RWDC/RODC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC/RODC will tell the computer in which AD site the computer is in, in which AD site the RWDC/RODC is in and the "close proximity bit" specifying if the RWDC/RODC is in the same AD site as the AD client.
         
      2. If the RWDC/RODC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site (in this case the AD client moved to a new AD site, got a new IP address, but the AD subnet was not defined yet or the AD subnet was not linked to an AD site), the RWDC/RODC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug). In the case of an RODC, it that RODC does not have the password cached of the computer, the RODC will then forward authentication to the RWDC with which the RODC has setup the secure channel
         
2. It DOES NOT know the AD site it is in, OR site specific DCs are not responding
   
   1. It queries DNS with "_ldap._tcp.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the domain-wide SRV records for <FQDN AD DOMAIN> (By default this will be done by all RWDCs in the AD domain. In scenarios where datacenters are used with branches, it is a best practice to configure RWDCs in the branches not to register domain-wide SRV records. RODCs do not register domain-wide SRV records by default, and again by default register only the site-wide SRV records and also do not perform automatic site coverage.)
      
   3. The computer contacts the RWDC (through LDAP ping, UDP:389).
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC will check if it can match the IP address of the computer to an AD subnet (as specific as possible)
      
      1. Assuming the RWDC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. Assuming it can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in. The computer will then repeat the process as specified in option [1] above.
         
      2. If the RWDC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug)
         

When a user then logs on to the computer, the AD domain information and the AD site information known to the computer will be used to find a DC and authenticate the user. So if the computer knows in which AD site it is in, to authenticate the user it will query DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>" and follow the steps as specified above in [1].

The steps above apply for authentication WITHIN the same AD forest and also BETWEEN AD forests or BETWEEN AD domains in different AD forests.

The following two scenarios exist, for which the steps are very very similar:

• User is logged on to computer in the same AD domain as the user and the user wants to access a resource in a different AD forest/domain (over an AD Forest Trust or an AD External Trust)
  
• User from one AD domain is logging on to a computer in another AD domain (over an AD Forest Trust or an AD External Trust)
  

Taking the first scenario as an example. When a user is logged on to the computer and the user wants to access a resource in another AD forest, it will query DNS with the following query: "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN OTHER AD DOMAIN>". Although it uses the FQDN of the AD forest the resource is in, it will use the AD site of the computer it is logged on to. If the AD site also exists in the other AD forest, then the steps as mentioned in step 1 will be used. If the AD site does not exist in that other AD forest, then the steps as mentioned in step 2 will be used, but then using <FQDN AD OTHER DOMAIN>. However, step 2d will be a little bit different. Based upon the IP address of the computer the RWDC of the other AD forest/domain will check if it can match the IP address of the computer to an AD subnet (as specific as possible) in the other AD forest .

[.A.] Assuming it can match the IP address to an AD subnet in the other AD forest and the AD subnet is linked to an AD site in the other AD forest, the RWDC will tell the computer in which AD site the computer is in in the other AD forest, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. The computer will then repeat the process as specified in step [1] above, but using the AD site in the other AD forest, OR…

[.B.] If the RWDC in the other AD forest cannot match the IP address of the computer to an AD subnet in the other AD forest OR if it can match the IP address to an AD subnet in the other AD forest but the AD subnet in the other AD forest is not linked to an AD site in the other AD forest, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug).

Within the same AD forest, if you get the "NO_CLIENT_SITE" error, it is not recommended to ignore this. To get rid of these errors make sure an AD subnet exists and that it is linked to an AD site. However, between AD forests it is very likely that this error occurs because the AD subnet structure and/or the AD site structure is different. Even if a match can be made, it may not even be the most optimal one to use. as the meaning of each AD site may be different. If you can ignore these errors or not between AD forest depends on the specific scenario.

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-01-23) Searching For Objects When Populating Reference Attributes In FIM – Available Options (Part 3)

This post explains the option to search for objects when using the " UsageKeyword Linking To A Search Scope ". Part 2 can be found here.

[Ad.2] "UsageKeyword Linking To A Search Scope"

In the screen below you see the "Computer Used By" attribute with the UocIdentityPicker control in the RCDC. You can also see that it’s value is pointing to another person object.

With this attribute, and of course any other similar attribute, you may want to make sure that only certain person objects (for example in specific location) are referenced. The next thing you need to think about is how are you going to mark an object so that you can define your filter? However, in this case any PERSON object was eligeable to be selected and it was not as important as with option 1 to be very precise. You should also be able to specify different search criteria (filters).

The only correct way to do this is by using the "UsageKeyword Linking To A Search Scope". Its configuration can be seen below.

First let’s explain the yellow marked options.

• Attribute Name: "computerUsedBy"
  
• Control Type: "UocIdentityPicker" –> enables you to select other objects to be specified as a value for the attribute;
  
• ColumnsToDisplay: "DisplayName,AccountName,Department " –> this is a list of attributes (specified by systemName) separated by a comma (,) that are shown when browsing for objects (after clicking the Browse button). However, this would only apply when using the "Filter Property" method and it is not used in this case;
  
• AttributesToSearch: "DisplayName,AccountName" –> this is a list of attributes (specified by systemName) separated by a comma (,) that are searched with the value that was specified by you (after clicking the Validate And Resolve button);
  
• UsageKeywords: "AllUsers,AllEmployees,AllContractors" –> this is a list of UsageKeywords separated by a comma (,) that are used in specific Search Scopes. In this case three Search Scopes exist and each have one of the UsageKeywords defined so that it is linked to this Identity Picker (also see picture below);
  
• ObjectTypes: "Person" –> when just specifying a value in the Identity Picker and resolving it, it would only be resolved against PERSON objects. This can be a list of objectTypes to search against and those are separated by a comma (,);
  
• Mode: "SingleResult" –> at all times the attribute can only have one single value. To be able to specify multiple value it should have had the value MultipleResult;
  
• ResultObjectType: "Person" –> The resource type is used to render objects matching the filter in the pop-up dialog-box list.
  

REMARK: In addition, additional filtering might be in effect because of configured permissions. For example, if you have people in Amsterdam and Seattle and you are only allowed to view person objects in the Seattle, then in your case as the person performing the query will be only to match PERSON objects in Seattle.

Advantages:

• When clicking the Browse button it does not return results right away (as shown in the picture below). If the list of quite large, it enables you to search based upon the selected Search Scope
  

Disadvantages:

• The only filters here are the objectType defined and the permissions to be able to query (view) the objects of the same objectType. If this option is used in the previous scenario you are able to select objects that should not be specified.
  

More information about controls in RCDCs: Resource Control Display Configuration XML Reference

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

(2011-01-23) Searching For Objects When Populating Reference Attributes In FIM – Available Options (Part 2)

This post explains the option to search for objects when using the "Filter Property". Part 1 can be found here.

 

[Ad.1] "Filter Property"

In the screen below you see the "manager" attribute with the UocIdentityPicker control in the RCDC. You can also see that it’s value is pointing to another person object.

With this attribute, and of course any other similar attribute like the "Assistant" attribute, you want to make sure that only person objects are referenced that represent people that are managers. The next thing you need to think about is how are you going to mark an object as belonging to a manager? In this simple example, a person being a manager, independent of department, location or project would have the "JobTitle" attribute configured with the word "Manager". Anyone else that’s not a manager must not be specified here, even by mistaken.

The only correct way to do this is by using the "Filter Property". Its configuration can be seen below.

First let’s explain the yellow marked options.

• Attribute Name: "Manager"
  
• Control Type: "UocIdentityPicker" –> enables you to select other objects to be specified as a value for the attribute;
  
• Mode: "SingleResult" –> at all times the attribute can only have one single value. To be able to specify multiple value it should have had the value MultipleResult;
  
• ObjectTypes: "Person" –> when just specifying a value in the Identity Picker and resolving it, it would only be resolved against PERSON objects. This can be a list of objectTypes to search against and those are separated by a comma (,);
  
• ColumnsToDisplay: "DisplayName,AccountName,EmployeeType,EmployeeStatus,JobTitle,Department,OfficeLocation" –> this is a list of attributes (specified by systemName) separated by a comma (,) that are shown when browsing for objects (after clicking the Browse button);
  
• AttributesToSearch: "DisplayName,AccountName,Department" –> this is a list of attributes (specified by systemName) separated by a comma (,) that are searched with the value that was specified by you (after clicking the Validate And Resolve button);
  
• Filter: "/Person[JobTitle = 'Manager']" –> Instead of searching against all PERSON objects, the search will only be carried out against all PERSON objects matching the filter;
  
• ResultObjectType: "Person" –> The resource type is used to render objects matching the filter in the pop-up dialog-box list.
  

REMARK: In addition to the Filter Property, additional filtering might be in effect because of configured permissions. For example, if you have managers in Amsterdam and Seattle and you are only allowed to view person objects in the Seattle, then in your case as the person performing the query will be only to match PERSON objects in Seattle for which the JobTitle equals Manager.

Advantages:

• Only objects matching the filter will be searched against. Therefore, objects not matching the filter will never be selected
  

Disadvantages:

• When clicking the Browse button you cannot search for objects and it returns the results right away (as shown in the picture below). If the list of quite large, it may take some time before you will find the required object.
  

Part 3 can be found here.

More information about controls in RCDCs: Resource Control Display Configuration XML Reference

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————