Wednesday, September 28, 2016

Check field Template Source value using sitecore powershell SPE

Use Case :Review

Suppose we have a custom rich text  and it has been sourced with custom component or css .This is added when developer creates template field in data template. The below code snippet can be used as part of your review and refactoring process to clean up sitecore items. 

Here is the quick pick..Check Source field of rich text is empy or null.

$targetTemplate    = Get-item 'master:/sitecore/templates/User Defined/Common/Data';
$templateFilter    = Get-Item "master:/sitecore/templates/System/Templates/Template Field";


Get-ChildItem $targetTemplate.FullPath -recurse 
| Where-Object { $_.TemplateName -eq $templateFilter.Name -and $_.type -eq 'Rich Text' -and $_["source"] -eq ''} 
| ForEach-Object {
    $_.Name
    $_.Type
    $_["Source"] 
}

Reference


http://sitecore.stackexchange.com/questions/203/unable-to-get-value-of-source-using-spe

Add base template using sitecore powershell extension

Use Case

It might happen you may have to add base template to all your user defined template. Below is the script to help doing this. I used Adam's code as reference to get this working. During development we could have reach to a stage where we end up with lot of user defined templates and at some point we review and refactor template to have uniform approach. One of the script below can come handy to save some of our refactoring time.

# Add base template programmatically


$targetTemplate    = Get-item 'master:/sitecore/templates/User Defined/Common/Data';
$templateFilter    = Get-Item "master:/sitecore/templates/System/Templates/Template";
$templateToBeAddAsBaseTemplate     = Get-Item 'master:/sitecore/templates/User Defined/Common/Data/Carousel'


Get-ChildItem $targetTemplate.FullPath -recurse | Where-Object { $_.TemplateName -eq $templateFilter.Name -and $_.Name -eq "promo"} | ForEach-Object {
    if(-not ($_."__Base template" -match "$($templateToBeAddAsBaseTemplate.Id)")){
           #If not exist then add
         $_."__Base template" = "$( $_."__Base template")|$($templateToBeAddAsBaseTemplate.Id)" 
    }
}

Reference

http://stackoverflow.com/questions/18990973/append-base-template-to-template-using-sitecore-powershell

Add base template using sitecore powershell extension

Use Case

It might happen you may have to add base template to all your user defined template. Below is the script to help doing this. I used Adam's code as reference to get this working. During development we could have reach to a stage where we end up with lot of user defined templates and at some point we review and refactor template to have uniform approach. One of the script below can come handy to save some of our refactoring time.



$targetTemplate    = Get-item 'master:/sitecore/templates/User Defined/Common/Data';
$templateFilter    = Get-Item "master:/sitecore/templates/System/Templates/Template";
$templateToBeAddAsBaseTemplate     = Get-Item 'master:/sitecore/templates/User Defined/Common/Data/Carousel'


Get-ChildItem $targetTemplate.FullPath -recurse | Where-Object { $_.TemplateName -eq $templateFilter.Name -and $_.Name -eq "promo"} | ForEach-Object {
    if(-not ($_."__Base template" -match "$($templateToBeAddAsBaseTemplate.Id)")){
           #If not exist then add
         $_."__Base template" = "$( $_."__Base template")|$($templateToBeAddAsBaseTemplate.Id)" 
    }
}

Reference

http://stackoverflow.com/questions/18990973/append-base-template-to-template-using-sitecore-powershell

Monday, September 12, 2016

Sitecore CMS Active Directory Module and LDAP integration.

Introduction

I'm not going to reinvent the wheel. The idea is to help fellow developer to troubleshoot and few show stoppers that can come as a problem during integration of ldap to sitecore AD Module. I just try to put my experience altogether so as to address some issues and useful tool that can help you get started.

Use Cases

Enabling LDAP authentication in content authoring aka CMS system will provide additional level of security access control in place. This will ensure limited access and no misuse even we have CMS -CA accessible only to internal network non accessible publicly.

Assumption:

You've LDAP /AD account in place. Say. There is dev, test and prod group account created in AD. To each of these group set of AD users are assigned. Each of these group must be assigned with Service account say sv_dev_user.and so on. The Service account act as primary source of authentication to allow any external system seek access to AD group. Later it will enable set of users to access application or system.

  • Development/Test/Production Environment
    • AD GROUP 
      • AD User(s) 
      • One Service Account
Note : The service account is one that is used by sitecore AD Module.

This is used by one of the sitecore configuration.
add name="customAD" type="LightLDAP.SitecoreADMembershipProvider" connectionStringName="LDAPConnString" applicationName="sitecore" minRequiredPasswordLength="1" minRequiredNonalphanumericCharacters="0" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
connectionUsername="[Enter SERVICE Account User Name]" connectionPassword="[Enter Password]" connectionProtection="Secure" attributeMapUsername="sAMAccountName" enableSearchMethods="true"

***Facts About:AD Service Account Vs AD User Account

In certain scenarios we have systems running under AD Credentials (i.e. under a Service Account). These Service Accounts are created in exactly the same way as user accounts; the only difference being the name and description. A few things have been done to make a distinction between the two account types (e.g. which OU the account is in, whether "password never expires" is enabled, if "service account" is in the description), but there's no one rule which can be applied to everything to clearly distinguish between the two.

How to get Started?

Follow this blog , this more precise and easy steps to start with.

Troubleshooting?  

1. OU Group wrongly used in LDAP Connection string?

Always look at the right form of LDAP connection string. 99% of the cases Ldap connection is wrongly used in terms of OU group. There may be nested OU group. The best way to figure out OU group is use LDAPAdmin.exe. Check download section.

Connect LdapAdmin with service account userId and pwd. Once connected to LDAPAdmin try to locate AD Group and take one member(user) of that group and check its property . You can easily find the right hierarchy of OU aswell as right OU group.

2. Check LDAP Port in Ldap connection string?

  • Port 389(used for ldap browsing) vs 636 (secure)
add name="LDAPConnString" connectionString="LDAP://Mydomain:389/OU=SomePrimaryOU,OU=SomeChildOU,DC=Mydomain,DC=myCompany,DC=com,DC=au"

3. Always verify connectivity of LDAP AD account from server

One way to check directly using ldapAdmin.exe or you can check through this simple code base.

using System.DirectoryServices;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            //mycompany.com.au
            var entry = new DirectoryEntry(@"LDAP://yourdomain:636/OU=primary,OU=secondary,DC=yourdomain,DC=mycompany,DC=com,DC=au", "Active directory user name","password");

            var search = new DirectorySearcher(entry);
            SearchResult result = search.FindOne();  

      }
      }
}

4. Sitecore Provider Status

                                       http://mydemo/sitecore/admin/providerstatus.aspx


5. User Manager : AD User Import Status Successful!


6. Domain: Check CustomAD Domain appeared!


7. Role Manager: Assign Sitecore Role to User

Make sure Sitecore Client Role is assigned to AD users.


8. Finally Login with AD user account

Ensure you using the domain name that you added as one of the membership provider. say you got domain name mydomain and you have used membership provider as below. Then you should login with customAD\UserId

add name="customAD" type="LightLDAP.SitecoreADMembershipProvider" connectionStringName="LDAPConnString" applicationName="sitecore" 

Last but not the least

If you unable to get any lead. Enable debug mode to true in ldap.config

Open the /App_Config/Include/ldap.config file, locate the LDAP.Debug setting and set it to true.
This setting is set to false by default. When the changes to the pluggable .config file are applied immediately, the next request to the module will dump much more information to the Sitecore CMS log file.

Downloads

References

Azure Cloud