TechOnTip Weblog

Run book for Technocrats

Archive for February, 2014

AD FS 2.0 Claims Rule Language Part 2

Posted by Brajesh Panda on February 26, 2014

Original: http://blogs.technet.com/b/askds/archive/2013/05/07/ad-fs-2-0-claims-rule-language-part-2.aspx

Hello, Joji Oshima here to dive deeper into the Claims Rule Language for AD FS. A while back I wrote a getting started poston the claims rule language in AD FS 2.0. If you haven’t seen it, I would start with that article first as I’m going to build on the claims rule language syntax discussed in that earlier post. In this post, I’m going to cover more complex claim rules using Regular Expressions (RegEx) and how to use them to solve real world issues.

An Introduction to Regex

The use of RegEx allows us to search or manipulate data in many ways in order to get a desired result. Without RegEx, when we do comparisons or replacements we must look for an exact match. Most of the time this is sufficient but what if you need to search or replace based on a pattern? Say you want to search for strings that simply start with a particular word. RegEx uses pattern matching to look at a string with more precision. We can use this to control which claims are passed through, and even manipulate the data inside the claims.

Using RegEx in searches

Using RegEx to pattern match is accomplished by changing the standard double equals “==” to “=~” and by using special metacharacters in the condition statement. I’ll outline the more commonly used ones, but there are good resourcesavailable online that go into more detail. For those of you unfamiliar with RegEx, let’s first look at some common RegEx metacharacters used to build pattern templates and what the result would be when using them.

Symbol

Operation

Example rule

^

Match the beginning of a string

c:[type == “http://contoso.com/role“, Value =~ “^director”]

=> issue (claim = c);

 
 

Pass through any role claims that start with “director”

$

Match the end of a string

c:[type == “http://contoso.com/email“, Value =~ “contoso.com$”]

=> issue (claim = c);

 
 

Pass through any email claims that end with “contoso.com”

|

OR

c:[type == “http://contoso.com/role“, Value =~ “^director|^manager”]

=> issue (claim = c);

 
 

Pass through any role claims that start with “director” or “manager”

(?i)

Not case sensitive

c:[type == “http://contoso.com/role“, Value =~ “(?i)^director”]

=> issue (claim = c);

 
 

Pass through any role claims that start with “director” regardless of case

x.*y

“x” followed by “y”

c:[type == “http://contoso.com/role“, Value =~ “(?i)Seattle.*Manager”]

=> issue (claim = c);

 
 

Pass through any role claims that contain “Seattle” followed by “Manager” regardless of case.

+

Match preceding character

c:[type == “http://contoso.com/employeeId“, Value =~ “^0+”]

=> issue (claim = c);

 
 

Pass through any employeeId claims that contain start with at least one “0”

*

Match preceding character zero or more times

Similar to above, more useful in RegExReplace() scenarios.

 
 

Using RegEx in string manipulation

RegEx pattern matching can also be used in replacement scenarios. It is similar to a “find and replace”, but using pattern matching instead of exact values. To use this in a claim rule, we use the RegExReplace() function in the value section of the issuance statement.

The RegExReplace() function accepts three parameters.

  1. The first is the string in which we are searching.
    1. We will typically want to search the value of the incoming claim (c.Value), but this could be a combination of values (c1.Value + c2.Value).
  2. The second is the RegEx pattern we are searching for in the first parameter.
  3. The third is the string value that will replace any matches found.

Example:

c:[type == “http://contoso.com/role“]

=> issue (Type = “http://contoso.com/role“, Value = RegExReplace(c.Value, “(?i)director”, “Manager”);

 
 

Pass through any role claims. If any of the claims contain the word “Director”, RegExReplace() will change it to “Manager”. For example, “Director of Finance” would pass through as “Manager of Finance”.

 
 

Real World Examples

Let’s look at some real world examples of regular expressions in claims rules.

Problem 1:

We want to add claims for all group memberships, including distribution groups.

Solution:

Typically, group membership is added using the wizard and selecting Token-Groups Unqualified Names and map it to the Group or Role claim. This will only pull security groups, not distribution groups, and will not contain Domain Local groups.


We can pull from memberOf, but that will give us the entire distinguished name, which is not what we want. One way to solve this problem is to use three separate claim rules and use RegExReplace() to remove unwanted data.

Phase 1: Pull memberOf, add to working set “phase 1”

 
 

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“http://test.com/phase1“), query = “;memberOf;{0}”, param = c.Value);

Example: “CN=Group1,OU=Users,DC=contoso,DC=com” is put into a phase 1 claim.

 
 

Phase 2: Drop everything after the first comma, add to working set “phase 2”

 
 

c:[Type == “http://test.com/phase1“]

=> add(Type = “http://test.com/phase2“, Value = RegExReplace(c.Value, “,[^\n]*”, “”));

Example: We process the value in the phase 1 claim and put “CN=Group1” into a phase 2 claim.

 
 

Digging Deeper: RegExReplace(c.Value, “,[^\n]*”, “”)

  • c.Value is the value of the phase 1 claim. This is what we are searching in.
  • “,[^\n]*” is the RegEx syntax used to find the first comma, plus everything after it
  • “” is the replacement value. Since there is no string, it effectively removes any matches.

 
 

Phase 3: Drop CN= at the beginning, add to outgoing claim set as the standard role claim

 
 

c:[Type == “http://test.com/phase2“]

=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/role“, Value = RegExReplace(c.Value, “^CN=”, “”));

Example: We process the value in phase 2 claim and put “Group1” into the role claim

Digging Deeper: RegExReplace(c.Value, “^CN=”, “”)

  • c.Value is the value of the phase 1 claim. This is what we are searching in.
  • “^CN=” is the RegEx syntax used to find “CN=” at the beginning of the string.
  • “” is the replacement value. Since there is no string, it effectively removes any matches.

 
 

Problem 2:

We need to compare the values in two different claims and only allow access to the relying party if they match.

Solution:

In this case we can use RegExReplace(). This is not the typical use of this function, but it works in this scenario. The function will attempt to match the pattern in the first data set with the second data set. If they match, it will issue a new claim with the value of “Yes”. This new claim can then be used to grant access to the relying party. That way, if these values do not match, the user will not have this claim with the value of “Yes”.

 
 

c1:[Type == “http://adatum.com/data1“] &&

c2:[Type == “http://adatum.com/data2“]

=> issue(Type = “http://adatum.com/UserAuthorized“, Value = RegExReplace(c1.Value, c2.Value, “Yes”));

 
 

Example: If there is a data1 claim with the value of “contoso” and a data2 claim with a value of “contoso”, it will issue a UserAuthorized claim with the value of “Yes”. However, if data1 is “adatum” and data2 is “fabrikam”, it will issue a UserAuthorized claim with the value of “adatum”.

 
 

Digging Deeper: RegExReplace(c1.Value, c2.Value, “Yes”)

  • c1.Value is the value of the data1 claim. This is what we are searching in.
  • c2.Value is the value of the data2 claim. This is what we are searching for.
  • “Yes” is the replacement value. Only if c1.Value & c2.Value match will there be a pattern match and the string will be replaced with “Yes”. Otherwise the claim will be issued with the value of the data1 claim.

 
 

Problem 3:

Let’s take a second look at potential issue with our solution to problem 2. Since we are using the value of one of the claims as the RegEx syntax, we must be careful to check for certain RegEx metacharacters that would make the comparison mean something different. The backslash is used in some RegEx metacharacters so any backslashes in the values will throw off the comparison and it will always fail, even if the values match.

Solution:

In order to ensure that our matching claim rule works, we must sanitize the input values by removing any backslashes before doing the comparison. We can do this by taking the data that would go into the initial claims, put it in a holding attribute, and then use RegEx to strip out the backslash. The example below only shows the sanitization of data1, but it would be similar for data2.

Phase 1: Pull attribute1, add to holding attribute “http://adatum.com/data1holder

 
 

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“http://adatum.com/data1holder“), query = “;attribute1;{0}”, param = c.Value);

Example: The value in attribute 1 is “Contoso\John” which is placed in the data1holder claim.

 
 

Phase 2: Strip the backslash from the holding claim and issue the new data1 claim

 
 

c:[Type == “http://adatum.com/data1holder“, Issuer == “AD AUTHORITY”]

=> issue(type = “http://adatum.com/data1“, Value = RegExReplace(c.Value,”\\”,””);

Example: We process the value in the data1holder claim and put “ContosoJohn” in a data1 claim

Digging Deeper: RegExReplace(c.Value,”\\”,””)

  • c.Value is the value of the data1 claim. This is what we are searching in.
  • “\\” is considered a single backslash. In RegEx, using a backslash in front of a character makes it a literal backslash.
  • “” is the replacement value. Since there is no string, it effectively removes any matches.

 
 

An alternate solution would be to pad each backslash in the data2 value with a second backslash. That way each backslash would be represented as a literal backslash. We could accomplish this by using RegExReplace(c.Value,”\\”,”\\”) against a data2 input value.

 
 

Problem 4:

Employee numbers vary in length, but we need to have exactly 9 characters in the claim value. Employee numbers that are shorter than 9 characters should be padded in the front with leading zeros.

Solution:

In this case we can create a buffer claim, join that with the employee number claim, and then use RegEx to use the right most 9 characters of the combined string.

Phase 1: Create a buffer claim to create the zero-padding

 
 

=> add(Type = “Buffer”, Value = “000000000”);

 
 

Phase 2: Pull the employeeNumber attribute from Active Directory, place it in a holding claim

 
 

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“ENHolder”), query = “;employeeNumber;{0}”, param = c.Value);

 
 

Phase 3: Combine the two values, then use RegEx to remove all but the 9 right most characters.

 
 

c1:[Type == “Buffer”]

&& c2:[Type == “ENHolder”]

=> issue(Type = “http://adatum.com/employeeNumber“, Value = RegExReplace(c1.Value + c2.Value, “.*(?=.{9}$)”, “”));

Digging Deeper: RegExReplace(c1.Value + c2.Value, “.*(?=.{9}$)”, “”)

  • c1.Value + c2.Value is the employee number padded with nine zeros. This is what we are searching in.
  • “.*(?=.{9}$)” represents the last nine characters of a string. This is what we are searching for. We could replace the 9 with any number and have it represent the last “X” number of characters.
  • “” is the replacement value. Since there is no string, it effectively removes any matches.

 
 

Problem 5:

Employee numbers contain leading zeros but we need to remove those before sending them to the relying party.

Solution:

In this case we can pull employee number from Active Directory and place it in a holding claim, then use RegEx to use the strip out any leading zeros.

Phase 1: Pull the employeeNumber attribute from Active Directory, place it in a holding claim

 
 

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname“, Issuer == “AD AUTHORITY”]

=> add(store = “Active Directory”, types = (“ENHolder”), query = “;employeeNumber;{0}”, param = c.Value);

 
 

Phase 2: Take the value in ENHolder and remove any leading zeros.

 
 

c:[Type == “ENHolder”]

=> issue(Type = “http://adatum.com/employeeNumber“, Value = RegExReplace(c.Value, “^0*”, “”));

Digging Deeper: RegExReplace(c.Value, “^0*”, “”)

  • c1.Value is the employee number. This is what we are searching in.
  • “^0*” finds any leading zeros. This is what we are searching for. If we only had ^0 it would only match a single leading zero. If we had 0* it would find any zeros in the string.
  • “” is the replacement value. Since there is no string, it effectively removes any matches.

 
 

Conclusion

As you can see, RegEx adds powerful functionality to the claims rule language. It has a high initial learning curve, but once you master it you will find that there are few scenarios that RegEx can’t solve. I would highly recommend searching for an online RegEx syntax tester as it will make learning and testing much easier. I’ll continue to expand the TechNet wiki article so I would check there for more details on the claims rule language.

Understanding Claim Rule Language in AD FS 2.0

AD FS 2.0: Using RegEx in the Claims Rule Language

Regular Expression Syntax

AD FS 2.0 Claims Rule Language Primer

Until next time,

Joji “Claim Jumper” Oshima

 
 

From <http://blogs.technet.com/b/askds/archive/2013/05/07/ad-fs-2-0-claims-rule-language-part-2.aspx>

Advertisements

Posted in Mix & Match | Leave a Comment »

AD FS 2.0 Claims Rule Language Primer – Ask the Directory Services Team – Site Home – TechNet Blogs

Posted by Brajesh Panda on February 26, 2014

Original: https://blogs.technet.com/b/askds/archive/2011/10/07/ad-fs-2-0-claims-rule-language-primer.aspx

 
 

Hi guys, Joji Oshima here again. On the Directory Services team, we get questions regarding the Claims Rule Language in AD FS 2.0 so I would like to go through some of the basics. I’ve written this article for those who have a solid understanding of Claims-based authentication. If you would like to read up on the fundamentals first, here are some good resources.

An Introduction to Claims

http://msdn.microsoft.com/en-us/library/ff359101.aspx

Security Briefs: Exploring Claims-Based Identity

http://msdn.microsoft.com/en-us/magazine/cc163366.aspx

AD FS 2.0 Content Map

http://social.technet.microsoft.com/wiki/contents/articles/2735.aspx

Claims Rules follow a basic pipeline. The rules define which claims are accepted, processed, and eventually sent to the relying party. You define claims rules as a property of the Claims Provider Trust (incoming) and the Relying Party Trust (outgoing).


Basic flowchart for the Claims Pipeline taken from TechNet.

There is also an authorization stage checks if the requestor has access to receive a token for the relying party. You can choose to allow all incoming claims through by setting the Authorization Rules to Permit All. Alternately, you could permit or deny certain users based on their incoming claim set. You can read more about authorization claim rules here and here.

You can create the majority of claims issuance and claims transformations using a Claim Rule Template in AD FS 2.0 Management console, but there are some situations where a custom rule is the only way to get the results you need. For example, if you want to combine values from multiple claims into a single claim, you will need to write a custom rule to accomplish that. To get started, I would recommend creating several rules through the Claim Rule Templates and view the rule language generated. Once you save the template, you can click the View Rule Language button from the Edit Rule window to see how the language works.


 
 


In the screenshot above, the rule translates as follows:

If (there is an incoming claim that matches the type “http://contoso.com/department“)

Then (issue a claim with the type “http://adatum.com/department“, using the Issuer, Original Issuer, Value, and ValueType of the incoming claim)

The claims “http://contoso.com/department” and “http://adatum.com/department” are URIs. These claims can be in the URN or HTTP format. The HTTP format is NOT a URL and does not have to specifically link to actual content on the Internet or intranet.

Claims Rule Language Syntax:

Typically, the claims rule language is structured similarly to an “if statement” in many programming languages.

If (condition is true)

Then (issue a claim with this value)

What this says is “if a condition is true, issue this claim”. A special operator “=>” separates the condition from the issuance statement and a semicolon ends the statement.

Condition statement => issuance statement;

Review some of the claims you created and look at the structure. See if you can pick out each part. Here is the one we looked at in the first section. Let’s break it down in to the basic parts.


The “if statement” condition:

The special operator:

  • =>

The issuance statement:

  • issue(Type = “http://adatum.com/department“, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

For each rule defined, AD FS checks the input claims, evaluates them against the condition, and issues the claim if the condition is true. You probably notice the variable “C” in the syntax. Think of “C” as an incoming claim that you can check conditions against, and use values from it to add to an outgoing claim. In this example, we are checking if there is an incoming claim that has a type that is “http://contoso.com/department“. We also use the values in this claim to assign the value of Issuer, OriginalIssuer, Value, and ValueType to the outgoing claim.

There are exceptions to this that are discussed later (using ADD instead of ISSUE and issuing a claim without a condition statement).

Issue a claim to everyone:

In the Claims Rule Language, the condition part is optional. Therefore, you can choose to issue or add a claim regardless of what claims are incoming. To do this, start with the special operator “=>“.

Syntax:

You could set similar rules for each Claims Provider Trust so that the Relying Party (or application) can know where the user came from.

Using a Single Condition:

In this example, we will look at a single condition statement. A basic claim rule checks to see if there is an incoming claim with a certain type and if so, issue a claim.

You can create this claim rule using the GUI. Choose the template named “Pass Through or Filter an Incoming Claim” and choose the appropriate incoming claim type.


Screenshot: Entries for a simple pass through claim.

You may also check for multiple values within your condition statement. For example, you can check and see if there is an incoming claim with a specific value. In the following example, we will check for an incoming claim with the type “http://contoso.com/role” that has the value of “Editors” and, if so, issue the exact same claim.

You can create this claim rule using the GUI as well. Choose “Pass Through or Filter an Incoming Claim”, choose the appropriate incoming claim type, select “Pass though only a specific claim value”, then enter the appropriate value.


Screenshot: Entries to pass through the Role claim if the value is “Editors”

Using Multiple Conditions:

Say you want to issue a claim only if the user has an Editor and has an Email claim and, if so, issue the Editor Role claim. To have multiple conditions, we will use multiple “C” variables. We will join the two condition statements with the special operator “&&“.

The first condition (c1) checks to see if you have an incoming role claim with the value of Editors. The second condition (c2) checks to see if there is an incoming email claim. If both conditions are met, it will issue an outgoing claim identical to the incoming c1 claim.

Combining Claim Values:

Say you want to join information together from multiple incoming claims to form a single outgoing claim. The following example will check for an incoming claim type of “http://contoso.com/location” and “http://contoso.com/role“. If it has both, it will issue a new claim, “http://contoso.com/targeted“, combining the two values.

The resulting value is the value of the first claim (c1), plus a space, plus the value of the second claim (c2). You can combine static strings with the values of the claims using the special operator “+“. The example below shows a sample set of incoming claims, and the resulting output claim.

Example Incoming Claims:

http://contoso.com/location” is “Seattle”

http://contoso.com/role” is “Editor”

Example Outgoing Claim:

http://contoso.com/targeted” is “Seattle Editor”

Using ADD instead of ISSUE:

As mentioned in an earlier section, you can ADD a claim instead of ISSUE a claim. You may be wondering what the difference between these two statements are. Using the ADD command instead of the ISSUE command will add a claim to the incoming claim set. This will not add the claim to the outgoing token. Use this for adding placeholder data to use in subsequent claims rules.


This illustration was taken from a TechNet article. Here you can see that the first rule adds a role claim with the value of Editor. It then uses this newly added claim to create a greeting claim. Assuming these are the only two rules, the outgoing token will only have a greeting claim, not a role claim.

I’ve outlined another example below.

Sample Rule 1:

Sample Rule 2:

c:[Type == “http://contoso.com/location“, Value==”LAX”]

=> add(Type = “http://contoso.com/region“, Value = “West”);

Sample Rule 3:

In this example, we have two rules that ADD claims to the incoming claim set, and one that issues a claim to the outgoing claim set. This will add a region claim to the incoming claim set and use that to create combine the values to create an area claim. The ADD functionality is very useful with the next section for aggregate functions.

Using aggregate functions (EXISTS and NOT EXISTS):

Using aggregate functions, you can issue or add a single output claim instead of getting an output claim for each match. The aggregate functions in the Claims Rule Language are EXISTS and NOT EXISTS.

Say we want to use the location claim, but not all users have it. Using NOT EXISTS, we can add a universal location claim if the user does not have one.

In Sample Rule 1, we will add a location claim with the value of “Unknown” if the user does not have a location claim. In Sample Rule 2, we will use that value to generate the “http://contoso.com/targeted” claim.

Sample Rule 1:

This way, users without the “http://contoso.com/location” claim can still get the “http://contoso.com/targeted” claim.

Claims Rule Language, beyond this post:

There is more you can do with the Claims Rule Language that goes beyond the scope of this blog post. If you would like to dig deeper by using Custom Attribute Stores and using Regular Expressions in the language, I’ve put up a TechNet Wiki article that contains these advanced topics and other sample syntax. In addition, some other articles may help with these topics.

Understanding Claim Rule Language in AD FS 2.0:

http://social.technet.microsoft.com/wiki/contents/articles/4792.aspx

When to Use a Custom Claim Rule:

http://technet.microsoft.com/en-us/library/ee913558(WS.10).aspx

The Role of the Claim Rule Language:

http://technet.microsoft.com/en-us/library/dd807118(WS.10).aspx

The Role of the Claims Engine:

http://technet.microsoft.com/en-us/library/ee913582(WS.10).aspx

The Role of the Claims Pipeline:

http://technet.microsoft.com/en-us/library/ee913585(WS.10).aspx

Conclusion:

Creating custom rules with the Claims Rule Language gives you more flexibility over the standard templates. Syntax familiarization takes a while, but with some practice, you should be able to write custom rules in no time. Start by writing custom rules instead of using the templates in your lab environment and build on those.

– Joji “small claims court” Oshima

 
 

Inserted from <https://blogs.technet.com/b/askds/archive/2011/10/07/ad-fs-2-0-claims-rule-language-primer.aspx>

Posted in Mix & Match | Leave a Comment »

Exchange Calendar Additional Response HTML Formatting

Posted by Brajesh Panda on February 21, 2014

In last couple of weeks we were setting up our 1st Lync Room System solution from Crestron. To bring awareness about Lync Room System, I used Calendar Additional Response feature in the room mailbox. You can set this txt using shell or MMC GUI

Shell – Set-CalenderResponse – id <Identity> -AddAddtionalResponse $True –AdditionalRespone “TXT”

MMC Gui – Mailbox Properties – Resource Information – Additional Text

Here is the html formatted message for your response & how it looks 😉

If your meeting request was declined please disregard the rest of this message. <p align="justify"> This message is intended to help with using the new Lync Room System (LRS) in Wilanow Palace. If your meeting request was accepted: Congratulations, you have scheduled a meeting with LRS in this meeting room! LRS is a combination of software and hardware that enables rich meeting scenarios, including video conferencing, white boarding, PowerPoint sharing, and more. We are excited to have you try LRS, and we would love to hear your feedback! To use LRS, you need to schedule a Lync Meeting. Key Scenarios: </p>

<p align="justify"><STRONG>1.) Join Meeting. </STRONG> If you’re reading this mail, you’ve already scheduled a meeting. Just touch the join button on your scheduled meeting to join it. Don’t see a join button? Make your meeting an online meeting in Outlook. </p>

<p align="justify"><STRONG>2.) Launch Whiteboard. </STRONG> You can start white boarding, and then invite participants to share the whiteboard. You can also start white boarding from within a meeting. </p>

<p align="justify"><STRONG>3.) PowerPoint Sharing. </STRONG> You can share your PPT slides with the room. To do this, upload the PPT file into the meeting from your machine (just as in Lync). From the room, you can then watch the PPT presentation, or take control and present. </p>

<p align="justify"><STRONG>4.) Display Modes. </STRONG>Try using different display modes to see which one best fits your meeting. </p>

<p align="justify"> If you run into any issues or have any questions, ideas, or feedback for the feature team, please contact us: Service Desk (ServiceDesk@TechOnTip.com) Thanks! </p>

Your request was accepted.

_____

If your meeting request was declined please disregard the rest of this message.

This message is intended to help with using the new Lync Room System (LRS) in Wilanow Palace. If your meeting request was accepted: Congratulations, you have scheduled a meeting with LRS in this meeting room! LRS is a combination of software and hardware that enables rich meeting scenarios, including video conferencing, white boarding, PowerPoint sharing, and more. We are excited to have you try LRS, and we would love to hear your feedback! To use LRS, you need to schedule a Lync Meeting. Key Scenarios:

1.) Join Meeting. If you’re reading this mail, you’ve already scheduled a meeting. Just touch the join button on your scheduled meeting to join it. Don’t see a join button? Make your meeting an online meeting in Outlook.

2.) Launch Whiteboard. You can start white boarding, and then invite participants to share the whiteboard. You can also start white boarding from within a meeting.

3.) PowerPoint Sharing. You can share your PPT slides with the room. To do this, upload the PPT file into the meeting from your machine (just as in Lync). From the room, you can then watch the PPT presentation, or take control and present.

4.) Display Modes. Try using different display modes to see which one best fits your meeting.

If you run into any issues or have any questions, ideas, or feedback for the feature team, please contact us: Colliers Service Desk (ServiceDesk) Thanks!

_____

Sent by Microsoft Exchange Server 2013

Posted in Mix & Match | Leave a Comment »

How to migrate OU structure from one domain to another

Posted by Brajesh Panda on February 19, 2014

How to migrate OU structure from one domain to another

iSiek's blog about Microsoft Windows services

Sometimes you may face an “issue” when you are migrating domain, using ADMT or another tool which does not support OU migration, to the new domain within the same forest or to completely new one.

Do you need then to rebuild everything manually or resign from existing OU scheme? No, you can very simply extract OU structure from one domain and import it to another. To achieve that you need to only use LDIFDE command which is available on any Domain Controller.

In this example, I will show you how to export OUs from one domain to flat text file, modify appropriate part of that file and import it to the new domain.

As you can see below on a screen, in my test environment some Organizational Units already exist. I would like to keep them in my new forest but I do not want to recreate whole structure manually.

View original post 375 more words

Posted in Mix & Match | Leave a Comment »

Updating Multi Valued Active Directory Attributes

Posted by Brajesh Panda on February 12, 2014

Example: DepartmentNumber

  • If DepartmentNumber is empty it doesn’t show up with Active Directory Module
    • Get-ADUser <SamAccountName> –properties *
    • Get-ADObjet <DN> -Properties *
  • But Quest Module shows it, does not matter if it is empty or has a value
    • Get-QADUser <SamAccountName> -IncludeAllProperties

Update the DepartmentNumber

DepartmentNumber is a multivalued attribute so value cannot be just set; we need to use a method

  • Add method with Set
    • Get-ADUser <SamAccountName> -Properties * | Set-ADObject -Add @{departmentNumber = ‘058’}
    • Get-ADUser <SamAccountName> -Properties * | Set-ADUser -Add @{departmentNumber = ‘059’}
  • Remove method with Set
    • Get-ADUser <SamAccountName> -Properties * | Set-ADUser -Remove @{departmentNumber = ‘059’}
    • Get-ADUser <SamAccountName> -Properties * | Set-ADUser -Remove @{departmentNumber = ‘058’}
  • Replace with Set
  • Clear with Set

Note: op_substraction ( -=) and put method are not supported with active directory module

  • Using Set-QADUser –ObjectAttributes
    • Set-QADUser  -Identity <Identity> -ObjectAttributes @{AttributeName=@{Action=@(‘value1’,’value2’…)}}
      • AttributeName – The LDAP name of the attribute.
      • Action         – The action you want to perform on the attribute value(s). The values
        @(‘value1’,’value2’…) – An array of values.
        • Append  – Adds one or more values to the attribute while preserving any existing entries.
          Clear      – Removes all values and set the attribute value to null.
          Delete    – Removes one or more values from the attribute while preserving any other existing entries.
          Update   – Removes any existing values and then writes one or more new values to the attribute.

Posted in Mix & Match | Leave a Comment »

Office 365: Cannot login to Lync Online IM thru Exchange Online OWA!!

Posted by Brajesh Panda on February 10, 2014

Recently I moved my account to Lync Online. While testing different features noticed, I cannot login to Lync IM thru Exchange Online’s OWA. By the way my mailbox is also in Exchange Online.

Here is a technet article for that; http://technet.microsoft.com/en-us/library/hh533880.aspx

We need to have hosting provider for exchange online integration. After I created that, I am able to login & able to chat with others. Make sure you have switch on pop-up in your browser 😉

Posted in Mix & Match | 3 Comments »

Exchange Mailbox Folder Types

Posted by Brajesh Panda on February 10, 2014

While working on Exchange Mailbox Folder Permissions script, came across below Mailbox Folder types… Interesting. Can be retrieve using statistics command and foldertype properties.

Get-MailboxFolderStatistics <Identity> | select folderpath, foldertype | Group-Object foldertype | ft -AutoSize

Posted in Mix & Match | Leave a Comment »

 
%d bloggers like this: