Back in the days of Visual Studio.NET 2002, Microsoft was basically the only game in town for .NET IDEs. However, that story has changed significantly. Not only does Visual Studio 2012 come in a variety of packages, some of them completely free, but there are other non-Microsoft products available to choose from, such as SharpDevelop from IC# Code.

The point here is that there are many options, and quite a few of them are free. It is not necessary to buy an expensive tool to write .NET code. Although we do not endorse a particular tool, we will say that most .NET developers use Microsoft’s Visual Studio, and the free Express versions are suitable for our needs, so that is a reasonable place to start.

Although an IDE can be nice, we do not actually need one to write code for the .NET Framework. In fact, Microsoft provides a free downloadable SDK with all versions of the framework that includes all the tools we need to build .NET code. Though it is rarely done, it is certainly possible to dive right in with Notepad and a command prompt! There are also a variety of tools available, such as Jeff Key’s Snippet Compiler, that provide an experience similar to scripting, but with compiled code. In addition, all of the examples in this appendix can be accomplished in PowerShell since Windows PowerShell is built on top of the .Net Framework.

Depending on the operating system (OS) of the machine where you want to run .NET code, a version of the framework may already be included. Table A-1 summarizes which OS has what. An article at microsoft.com has an excellent diagram that shows the iterative versions of the framework and what version of the underlying CLR is used.

Unfortunately, once we include service packs and other factors, the matrix of possible options for .NET Framework installation across all of the different OS versions can get a little hairy. We will not attempt to document this completely and will instead defer to Microsoft’s own deployment guides for the details:

The .NET Framework includes a huge number of classes and other programming types. In order to keep things organized, these types are arranged in hierarchical groupings called namespaces. The core features of the framework are arranged under the System namespace.

There are now four main namespaces specifically used for directory services programming:

This does not include all of the other types we might need to access to perform additional programming tasks and also ignores access to WMI (something that .NET can do, but not something we will cover at all in this book).

In order to keep the framework modular, major pieces of functionality are compiled into separate components called assemblies. An assembly is essentially just a DLL. An assembly can contain types in multiple namespaces, and namespaces can span different assemblies. Do not let this confuse you, though.

There are three important things to know here:

Table A-2 summarizes which namespaces are available in which .NET Framework releases.

The bottom line is that .NET 2.0 contains the majority of the available features, but you need .NET 3.5 to get all of them. Looking at Table A-1, this also implies that you may need to get one of the newer versions of .NET installed where you want to run your code.

The System.DirectoryServices namespace (SDS) is the primary namespace we use for programming directory services in .NET. It is the oldest namespace, having been included with .NET since the very first 1.0 release.

SDS is basically just a simple interoperability layer over the existing ADSI programming model. Most of what you already know about ADSI will apply directly to SDS. SDS is in many ways like a stripped-down version of ADSI, but in other ways it is more powerful. In all cases, it is ADSI that does the bulk of the work, with the underlying components it depends on doing the actual heavy lifting.

Even though there are quite a few types in the namespace, almost everything in SDS revolves around two core classes:

DirectoryEntry is essentially a wrapper around the ADSI IADs interface and is most similar to programming with the familiar IADsOpenDSObject.OpenDSObject and GetObject methods. In fact, DirectoryEntry allows us to “drop down” into ADSI whenever we need to by exposing a NativeObject property that provides direct access to the underlying ADSI COM object.

DirectoryEntry is used to connect to the directory, refer to specific objects, read and write their attributes, create new objects, delete objects, and move objects. Everything starts with a DirectoryEntry object.

DirectorySearcher is the more interesting part of SDS. As its name implies, it allows us to search the directory via LDAP queries. In the ADSI scripting world, we use ActiveX Data Objects (ADO) for querying the directory via the ADSI OLE DB provider, while we use GetObject to access specific objects and perform modifications. This approach made it easier for developers accustomed to querying SQL databases to learn LDAP, but the two models were never well integrated, and ADO gets a little clunky when special features need to be accessed. Additionally, many of the powerful advanced LDAP query features supported by Active Directory never got exposed to ADO, so developers using this technology were basically out of luck.

DirectorySearcher takes a different approach. Instead of using a similar pattern and having .NET developers use the classes in System.Data to execute LDAP searches, the designers of the framework gave us a component purpose-built for doing LDAP queries. The main advantages are:

You’ll see how some of this looks when we show some examples in the upcoming sections.

Under the hood, DirectorySearcher accomplishes its magic by interoperating with a low-level ADSI interface called IDirectorySearch. IDirectorySearch has been in ADSI for a long time, but VB and VBScript developers could not call it directly as it was designed only for C++ developers. The ADSI OLE DB provider we use in VBScript is actually another wrapper around IDirectorySearch that adapts IDirectorySearch to the ADO programming model. With DirectorySearcher, we get a feature designed for LDAP programming and with all the special features exposed.

As its name implies, SDS.AD provides support for performing operations on Active Directory specifically. When we say Active Directory, we include both AD Domain Services and AD Lightweight Directory Services (AD LDS).

SDS.AD provides access to functions that previously were difficult or impossible for developers using languages other than C++ to access. The functions can be grouped into the following categories:

SDS.AD accomplishes this goal by using a clever design to marry the ADSI programming model to a set of non-LDAP RPC interfaces with function names like DsGetDCName. As we will see, SDS.AD is integrated tightly with SDS, making it easy to move between the two namespaces as needed.

Unlike SDS.AD, which layers new capabilities on top of the existing ADSI-based SDS, SDS.P is a completely different animal. Referring back to Figure A-1, we see that SDS.P does not layer on top of ADSI at all, but instead sits directly on top of the core Windows LDAP library, wldap32.dll. We also see that SDS.P does not overlap with SDS at all.

In a nutshell, SDS.P gives us a completely different model for programming LDAP. Instead of using the “object-centric” metaphor of ADSI, where you create programmatic objects that point to specific objects in the directory in order to manipulate them, SDS.P applies the “connection-centric” metaphor inherent in the standards-based LDAP API design. For example, in SDS.P we create a DirectoryConnection object to connect to the underlying directory, and then we perform operations on that connection by sending it messages such as search requests and receiving messages such as search responses in reply.

SDS.P implements just about every feature of the underlying LDAP API; it brings the full power of LDAP to the programmer, including many features not even supported by ADSI and thus not possible in SDS. It also provides the opportunity to get the best possible performance from LDAP in scenarios where performance trumps productivity (i.e., not usually scripting).

The downside of this is that SDS.P is more complicated and demands that you learn all of the intimate details of LDAP and AD programming. Basically, it is provided to support the needs of systems programmers rather than administrators or even normal enterprise developers.

Since its introduction in NET 1.0, SDS has often been criticized for being too difficult to use for performing common user- and groups-management tasks. It was seen as a step down from the approach provided by ADSI before it. Microsoft did not really do anything to address this shortcoming in .NET 2.0, but the 3.5 release changed this significantly.

In .NET 3.5, Microsoft introduced a new namespace and assembly called SDS.AM. Also called “the principal API,” SDS.AM significantly simplifies the tasks associated with managing directory security principals such as users, computers, and groups.

These are the design goals of SDS.AM:

Referring back to Figure A-1, we see that SDS.AM layers on top of SDS, with a bit of overlap with SDS.P as well. For the most part, SDS.AM is based on SDS and thus ADSI. In a way, we could say that SDS.AM reintroduces features ADSI always had with the IADsUser, IADsComputer, and IADsGroup interfaces, but in actuality it does ADSI one better. Because SDS.AM is much newer, it allowed the designers to purposefully include support for AD LDS and to take advantage of many .NET programming features that simplify development tasks. We will see this when we dive into the examples.

Referring to Figure A-2, we see that there are just a few primary classes within SDS.AM. On the left, we see a class called Principal with several other classes underneath it. The lines here are significant because they indicate an inheritance relationship. UserPrincipal derives from AuthenticablePrincipal, which derives from Principal, etc. Principal is essentially the center of the universe in SDS.AM. We can also derive our own classes from any of these classes as a way to extend SDS.AM to our own directory customizations.

Figure A-2. Primary classes in System.DirectoryServices.AccountManagement

PrincipalContext is a helper class used to create different types of Principal objects. Its primary job is to specify which type of directory we are accessing.

PrincipalSearcher and the classes underneath it are used for finding Principal objects in the directory and work in conjunction with PrincipalContext and Principal.

There are two basic options available for connecting to the directory:

Let’s look at some examples of each in turn. As we discussed earlier in the book, LDAP directories support a special object called RootDSE that allows the programmer to query the directory for information such as what partitions it contains, so we will start there:

'connect to rootDSE using "serverless binding"
Dim rootDSE As New DirectoryEntry("LDAP://RootDSE")

'this uses the full constructor to do the same thing
Dim rootDSE2 As New DirectoryEntry( _
    "LDAP://RootDSE", _
    Nothing, _
    Nothing, _
    AuthenticationTypes.Secure _
    )

'same as first but specifying a specific domain
Dim rootDSE3 As New DirectoryEntry( _
    "LDAP://mycorp.com/RootDSE")

'now we are using explicit credentials and
'Secure (negotiate) authentication
Dim rootDSE4 As New DirectoryEntry( _
    "LDAP://rootDSE", _
    "[email protected]", _
    "Password1", _
    AuthenticationTypes.Secure _
    )

'bind to LDS rootDSE as an AD LDS user using
'simple bind and SSL to protect the credentials
'on the network
Dim ldsRootDSE As New DirectoryEntry( _
    "LDAP://adldsserver.com/RootDSE", _
    "otheruser@adlds", _
    "Password1", _
    AuthenticationTypes.SecureSocketsLayer _
    )

The first thing to notice is that this looks quite a bit like GetObject or OpenDSObject in ADSI. This is no accident. The same technology is being used and the same rules apply. In .NET, we use a feature called “method overloading” to specify multiple constructors for the same object. This makes it easy to either use the defaults or specify explicit credentials and other options whenever we need to. We also show an example of connecting to AD LDS at the end. Again, the same rules apply, except that we cannot use “serverless binding” with AD LDS and must specify a server name.

In the AD LDS example, we connect using SSL and use LDAP simple bind instead of Windows secure bind.

AuthenticationTypes.Secure Or AuthenticationTypes.SecureSocketsLayer

Now, let’s read some attributes and connect to the domain root object:

'get the defaultNamingContext for this domain
Dim ncName As string = DirectCast( _
    rootDSE.Properties("defaultNamingContext").Value, _
    String)
Dim ncRoot As New DirectoryEntry("LDAP://" + ncName)

'now, let's use SDS.AD to do the same thing
'in one line of code!
Dim ncRoot2 As DirectoryEntry = _
    Domain.GetCurrentDomain().GetDirectoryEntry()

In this example, we show how to read LDAP attributes from the DirectoryEntry we created previously. Instead of using Get and GetEx like we do in ADSI, .NET implements a PropertyCollection that contains PropertyValueCollection objects. The Value property on PropertyValueCollection is a helper that returns:

This is handy, so we will use it frequently. Since attributes in AD can be of many different data types and .NET converts them to specific data types the same way that ADSI does, they are returned as Object. This means we must convert them back into the type they really are.

After that, we use the defaultNamingContext attribute value from RootDSE to build another DirectoryEntry, this time pointing to the domain partition root object.

Next, we use an alternate approach to accomplish the same goal in a single line of code using the Domain class. Obviously, this is less work and quite handy. Here are some other examples with the Domain class:

'create a Domain-type DirectoryContext pointing to
'a specific domain with default credentials
Dim context1 As New DirectoryContext( _
    DirectoryContextType.Domain, _
    "othercorpdomain.com" _
    )
'build a Domain object with the context
Dim domain1 As Domain = Domain.GetDomain(context1)
'create a Domain-type DirectoryContext pointing to
'a specific domain with alternate plaintext credentials
Dim context2 As New DirectoryContext( _
    DirectoryContextType.Domain, _
    "othercorpdomain.com", _
    "[email protected]", _
    "Password1" _
    )
Dim domain2 As Domain = Domain.GetDomain(context2)

With SDS.AD, we use an object called DirectoryContext as a way to build all sorts of different types of objects, such as domains, forests, specific servers, and even AD LDS configuration sets or AD application partitions. We see this pattern repeated in SDS.AM with the PrincipalContext class.

As we said before, SDS.AD provides a vast array of AD management features, and we do not have room here to even scratch the surface. Some of our favorite features include the ability to expand the complete domain tree and locate Global Catalog servers, from which you can directly construct a DirectorySearcher for searching the GC. We’ll end with one final example showing how to enumerate domain controllers in a specific domain, since nearly everyone has to do this from time to time:

Dim currentDomain As Domain = Domain.GetCurrentDomain()
For Each dc As DomainController _
    In currentDomain.FindAllDomainControllers()
    'we can do whatever we want now that we have all the DCs...
    Console.WriteLine(dc.Name)
Next

The example is trivially easy, and that is really the whole point. SDS.AD takes tasks that can range from annoying to nearly impossible and makes them easy to accomplish.

Dim entry As New DirectoryEntry("LDAP://RootDSE")
Using (entry)>
    'do something with the DirectoryEntry here...
End Using

One of the primary reasons we have a directory in the first place is to look up information in it, so it stands to reason that searching the directory is one of the things we’ll do most often. Let’s look at some basic examples of searching with DirectorySearcher:

Dim root As DirectoryEntry = _
    Domain.GetCurrentDomain().GetDirectoryEntry()
Dim searcher As New DirectorySearcher(root)
searcher.Filter = "(&(objectCategory=person)(objectClass=user))"
searcher.SearchScope = SearchScope.SubTree

'we only want this attribute returned, so specify it
searcher.PropertiesToLoad.Add("sAMAccountName")

'enable paging by setting a nonzero page size
searcher.PageSize = 1000
Dim src As SearchResultCollection
Using (src)
    src = searcher.FindAll()
    For Each result As SearchResult In src
        Console.WriteLine(result.Properties("sAMAccountName")(0))
    Next
End Using

A DirectorySearcher object always needs a DirectoryEntry to use as a way of establishing the connection to the directory and determining which object will be the base of the search. In this example, we use our previous shortcut with SDS.AD to build a DirectoryEntry pointing to the domain partition root object for this purpose. Note that you can build a DirectorySearcher without specifying this, and SDS will try to do this for you, but it is nearly always better to be explicit about your intent in your code.

We use a standard filter for finding user objects and set the scope to SubTree, even though that is not technically necessary since it is the default. We also add the sAMAccountName attribute to the list of PropertiesToLoad to specify that we want only that attribute returned instead of the default of “all,” as per normal LDAP rules.

We also set the PageSize to 1000 to enable paged searches. As with other ADSI-based searches, we do not explicitly loop through the pages of results returned by the server under the hood. ADSI does this for us. Generally speaking, it is always a good idea to enable paged searches as we usually want to get all of the results, even if there are more than 1,000. If there are less than 1,000, the paging request does not hurt anything.

To enumerate the results, we use a For Each loop against the SearchResultCollection object returned by the call to FindAll. Note that this approach provides better performance than using a For loop based on the Count property of the SearchResultCollection. This has to do with the fact that in order to get the Count, the entire search must be run under the hood anyway. Using For Each instead fetches the results as they are returned.

Notice that like DirectoryEntry, the SearchResult class also has a Properties property that provides access to the attribute values returned by the search. They behave similarly, except that SearchResult objects are strictly read-only and the ResultPropertyValueCollection does not have a handy Value property like the PropertyValueCollection, so we must access the first value returned by indexing into the array. Make sure that if you access an attribute that might be null, you first check to see if the SearchResult contains that attribute using the Contains method. Otherwise, indexing into the array will result in an error:

If result.Properties.Contains("displayName") Then
    Console.WriteLine(result.Properties("displayName")(0))
End If

DirectorySearcher is also the place where many of the special features in AD LDAP are lurking. For example, DirectorySearcher provides access to things like attribute scope queries, directory synchronization, virtual list views, deleted object searches, and Extended DN Queries. Once again, we are pressed for space in this book, but check out some of the other resources available to find out how to use these advanced features if you find yourself in need of them.

Now that we have some of the basics covered, let’s turn our attention to modifying the directory. After all, searching is only useful if someone puts some objects in the directory first.

We have a few options when it comes to modifying the directory. SDS allows us to create, modify, or delete just about any type of object in the directory that we can think of, as long as we know how. It is our workhorse for modifications, so we will start with it.

On the other hand, much of an administrator’s life tends to revolve around modifying security principals in the directory, such as users, computers, and groups. As we’ve already learned, the namespace in introduced .NET 3.5, SDS.AM, gives us a simple, powerful way to manipulate those types of objects specifically. In the next section, we will show some samples for performing those tasks, using both namespaces for contrast.

Finally, SDS.AD again provides us with a rich set of features for modifying AD infrastructure objects such as sites, trusts, and the schema (which is almost always a bad idea to modify in code, but this is sometimes necessary). This essentially allows you to build your own versions of the AD Domains and Trusts, Sites and Services, and Schema Management MMC snap-ins, if you so desire. While we won’t look at these types of scenarios in depth, we do want you to know where to look if the need arises.

Dim root As DirectoryEntry = _
    Domain.GetCurrentDomain().GetDirectoryEntry()
Dim newOU As DirectoryEntry = _
    root.Children.Add("OU=New OU", "organizationalUnit")
newOU.Properties("description").Value = "A new OU"
newOU.CommitChanges()

root.Children.Remove(newOU)

newOU.DeleteTree()

Dim firstOU As New DirectoryEntry( _
    "LDAP://OU=First OU,DC=mycorp,DC=com")
Dim newParent as New DirectoryEntry( _
    "LDAP://OU=Second OU,DC=mycorp,DC=com")

'choose one or the other!!!
'this one moves without renaming
firstOU.MoveTo(newParent)

'this one moves and renames
firstOU.MoveTo(newParent, "OU=Child OU")

Dim toBeRenamed As New DirectoryEntry( _
    "LDAP://OU=Second OU,DC=mycorp,DC=com")
toBeRenamed.Rename("OU=A different name")

Dim entry as New DirectoryEntry( _
    "LDAP://CN=test,OU=People,DC=mycorp,DC=com")

entry.Properties("displayName").Value = "new name"
entry.Properties("description").Value = "new description"
entry.CommitChanges()

Now that we have the basics of directory modifications mastered, let’s look at a few user management examples. As we have learned by now, effective user management comes down to knowing many of the picky little details about how data is stored in the directory and how to change it to get the results we need. Let’s start with a simple user creation sample:

Dim parent As DirectoryEntry = New DirectoryEntry( _
    "LDAP://OU=people,DC=mycorp,DC=com")
Dim user As DirectoryEntry = _
    parent.Children.Add("CN=test.user", "user")
user.Properties("sAMAccountName").Value = "test.user"
user.Properties("userPrincipalName").Value = "[email protected]"
user.CommitChanges()

This looks fairly similar to our previous example of creating an OU, except that we set some different attributes for the user object. The problem with this is that this user will not have a password and will be disabled by default, so it is not very useful yet. Additionally, if we have a password policy in place requiring passwords, we cannot enable the user until after we have set a password. Let’s revise our sample:

Dim parent As DirectoryEntry = New DirectoryEntry( _
    "LDAP://OU=people,DC=mycorp,DC=com")
Dim user As DirectoryEntry = _
    parent.Children.Add("CN=test.user", "user")
user.Properties("sAMAccountName").Value = "test.user"
user.Properties("userPrincipalName").Value = "[email protected]"
user.CommitChanges()

'this is how we call an IADsUser method
user.Invoke("SetPassword", New Object() {"Password1"})
'this is how we call an IADsUser property method
user.InvokeSet("AccountDisabled", New Object() {False})
'or we could do this, which is faster:
user.Properties("userAccountControl").Value = 512 'normal

'force password change at next logon
user.Properties("pwdLastSet").Value = 0
user.CommitChanges()

Suddenly, our sample is getting a little complex. First, notice that we use a method on DirectoryEntry called Invoke to call methods on underlying ADSI interfaces. In this case, we call IADsUser.SetPassword. Invoke takes an array of objects as its other argument (although in this case it really just wanted a single string), because the method we could be calling under the hood might take any number of different arguments of any type and we need a generic mechanism to make this work.

Next, we see a call to InvokeSet. While Invoke is used for calling ADSI methods, InvokeGet and InvokeSet are used specifically for calling the set and get versions of ADSI properties—in this case, IADsUser.AccountDisabled. We also show how you could set userAccountControl directly instead of using the ADSI property, although we cheat a little by setting a direct numeric value instead of changing the single bit we need to flip in order to remove the disabled flag. In general, setting this attribute to an arbitrary value is bad practice. Instead, we should manipulate the individual bit flags to avoid overwriting other settings and make our intentions in our code more clear.

Finally, we set the pwdLastSet attribute to 0 to force the user to change her password at the next login and call the CommitChanges method to update the object in the directory.

We also see that we have to do this whole thing in three steps. We cannot call SetPassword on an object that has not been created yet, and we cannot enable an object that has no password, so all three steps are needed.

Now, let’s pretend we need to add a user to AD LDS. In this case, we use a totally different method to enable the user. Instead of using userAccountControl, AD LDS uses the msds-userAccountDisabled Boolean attribute (set to False, as you might guess). While this is certainly easier to deal with than flipping individual bits on userAccountControl, the problem is that we need different code for different stores and have to keep track of all these details.

Once we throw in all of the rest of the user management functions, such as setting the home directory, account expiration, and so on, it gets messy quickly.

Dim principalContext As new PrincipalContext( _
    ContextType.Domain, _
    "MyCorp", _
    "OU=People,DC=mycorp,DC=com")
Dim newUser As New UserPrincipal( _
    principalContext, "test.user", "Password1", True)

Dim samContext As New PrincipalContext(ContextType.Machine)
Dim ldsContext As New PrincipalContext( _
    ContextType.ApplicationDirectory, _
    "localhost:50000", "OU=Users,O=Demo")

As promised, we have up to this point totally avoided any examples having to do with SDS.P, suggesting that it really is not intended for most programmers and not worth attempting to cover in a high-level introduction such as this one. We also promised one simple sample to show you what it looks like. This sample is also relevant because it is something you cannot do in ADSI at all.

The scenario is that our code needs to connect to an LDAP directory—possibly AD DS or LDS, but also maybe a non-Microsoft LDAP directory—and we need to use SSL. Unfortunately, there is a problem with the server’s SSL certificate. Perhaps the subject name on the certificate does not match the DNS name we must use to access the server, or perhaps we do not trust the certificate’s issuer on our client, or the certificate has expired. ADSI does support SSL/LDAP operations, but it will fail with a “Server Not Operational” error if there is anything wrong with the server’s certificate. This behavior cannot be changed, so with ADSI we are out of luck.

However, the Windows LDAP API does provide more options here (ADSI simply does not expose access to this advanced feature). Since SDS.P provides nearly the entire scope of Windows LDAP functionality, we also have access to this feature in SDS.P and can override the SSL verification logic:

Public Module MyModule
    Sub Main()
        Dim con As New LdapConnection( _
            new LdapDirectoryIdentifier( _
                "badserver.com:636", True, False))
        con.SessionOptions.SecureSocketLayer = True
        con.SessionOptions.VerifyServerCertificate = _
            AddressOf ServerCallback
        con.Credential = New NetworkCredential("", "")
        con.SessionOptions.SecureSocketLayer = True
        con.AuthType = AuthType.Anonymous
        con.Bind()

        'do a RootDSE search and get the currentTime attribute
        Dim search As New SearchRequest( _
            "", _
            "(objectClass=*)", _
            SearchScope.Base, _
            New String(){"currentTime"} _
            )
        Dim response As SearchResponse = _
            DirectCast(con.SendRequest(search), SearchResponse)
        For Each entry As SearchResultEntry In response.Entries
            Console.WriteLine(entry.Attributes("currentTime")(0))
        Next
    End Sub

    Function ServerCallback( _
        ByVal connection As LdapConnection, _
        ByVal certificate As X509Certificate _
        ) As Boolean
    'ignore errors; do not even check the certificate
    'just return true
        Return True
    End Function
End Module

Even though we have tried to scare you with the complexity of SDS.P, the code turns out to be fairly simple.

The main trick here is that we define a method called ServerCallback that implements a method signature of a specific delegate (basically a .NET callback function) defined in SDS.P called VerifyServerCertificateCallback. We tell our LdapConnection to call our callback function during SSL certificate verification by using the AddressOf keyword on the SessionOptions.VerifyServerCertificate member to point to our method. ServerCallback simply returns True, instructing the underlying code to accept the certificate presented by the server and ignore any errors. We could write something more intelligent by looking at the data in the certificate that is passed to us if we wished.

The rest of the code just sets up the connection to use SSL and anonymous authentication and connects to the directory using the Bind method. After that, we show a simple RootDSE search, a base scope query with a null search base specified, and return the currentTime attribute to demonstrate a simple search operation. However, the point here is not to demonstrate the search, but to show the SSL verification. We would not even get past the Bind method without our SSL verification override if there was a problem with the server’s certificate.