[Week 4] Google IT Support Professional Certificate #25 | Course 4 System Administration and IT Infrastructure Services {Part 1}

I just completed 4th week of course 4 in 7 days.

What I (We) learn in the 4th week of this course?

In the fourth week of this course, we'll learn about directory services. Specifically, we'll cover how two of the most popular directory services, Active Directory and OpenLDAP, work in action. We'll explore the concept of centralized management and how this can help SysAdmins maintain and support all the different parts of an IT infrastructure. By the end of this module, you will know how to add users, passwords, and use group policies in Active Directory and OpenLDAP.

To Join this course click on the link below

Google IT Support Professional Certificate http://bit.ly/2JONxKk

Our main objectives.

1. Understand what services a directory server provides.
2. Understand what LDAP and Active Directory are.

Meet Our trainer(s) for Course 4

Devan Sri-Tharan

His name is Devan Sri-Tharan, He've been working in IT for ten years. He is a Corporate Operations Engineer at Google where he get to tackle challenging and complex IT issues.

This is part 1 for part 2 click here------------------ http://bit.ly/2BYdNDI

Theory covered in Week 4

1. What is a directory server?

Have you ever looked up someone's phone number in a phone directory? Or use a directory listing at a shopping mall to find a specific store? A directory server essentially provides the same functionality. A directory server contains a lookup service that provides mapping between network resources and then network addresses. It's used to organize and look up organizational objects and entities ranging from things like user accounts, user groups, telephone numbers, and network shares. Instead of managing user accounts and computer information locally on every machine, all that information can be stored on a directory server for easy access and management. The ideal enterprise quality directory server should support replication. This means that the store directory data can be copied and distributed across a number of physically distributed servers but still appear as one unified data store for querying and administering. Why is replication important? It provides redundancy by having multiple servers available simultaneously. So there'll be minimal disruption to the service in the event that one of server explodes. Replication also decreases latency when you access the directory service. By having replicas of your directory server located in each office, you're able to answer directory service queries more quickly. The directory service should also be flexible, allowing you to easily create new object types as your needs change. Access to the information stored in the directory server database should be accessible from a variety of OS types and from the designated areas of the corporate network. Directory services are useful for organizing data and making it searchable for an organization. This is achieved through the use of a hierarchal model of objects and containers. The containers are referred to as organizational units or OUs, and they can contain objects or more organizational units. This is similar in organizational structure to a file system. OUs are like folders which can contain individual files or objects for a directory service. OUs can also contain additional folders. The management benefits of this structure are pretty clear. Can you imagine trying to keep your music library organized if there was no such thing as suborders? Crazy. This hierarchal structure can be used to convey additional information about what's stored within. Take your directory structure as an example. You may have an OU code users which contains all user accounts. Within this OU, there could be additional OUs which represent the actual team structure of your organization. The user's OU could contain additional OUs like sales, engineering, marketing which include the user account objects for the individuals that belong to these current teams.

This structure can be used to convey differences between these sub-OU sub-users. For example, we could influence stricter password requirements for members of engineering without affecting sales or marketing. Submembers inherit their characteristics of their parent OU. So any changes made to the higher level user's OU would affect all sub-OUs, including sales, marketing, and engineering. Someone with the responsibilities of a systems administrator, whether that's a system admin or I.T. support specialist, would be responsible for the set up, configuration, and maintenance of the territory server. This includes the OS itself on which the directory service would run. Standard OS management tasks are involved here, like ensuring that updates are installed and configuring standard services. Other responsibilities include the installation and configuration of the directory service itself. So installing the service and configuring any related services. If multiple servers are used in a replication setup, this needs to be configured, too. It's very likely that the hierarchy in overall structure of the directory itself would also be up to business admin to design and implement. Well, that covers the high level overview of what exactly a director service is. We'll dive deep into more specific details later in this course. But for now, let's review some of the concepts we just covered with a short quiz. Then list me back at the next where we'll do a more detailed rundown on how to implement directory services.

2. Implementing Directory Services

Directory services became an open network standard for interoperability among different software vendors. In 1988, the X.500 directory standard was approved and included protocols like Directory Access Protocol or DAP, Directory System Protocol or DSP, Directory Information Shadowing Protocol or DISP, and Directory Operational Bindings Management Protocol or DOP. Alternatives to DAP were designed to allow clients to access the X.500 directory. The most popular of these alternatives was lightweight directory access protocol or LDAP. Since these are open standards for communication and access for directory services, a bunch of different implementations of these services cropped up. There are offerings from Apache, Oracle, IBM, and Red Hat, but we'll cover two in more detail later in this module. The first is Microsoft's implementation, which is referred to as Active Directory or AD. It has some customization and added features for the Windows platform. There are also open source implementations of directory services using LDAP. A popular example of this is OpenLDAP, which we'll also cover in greater detail. OpenLDAP supports a wide range of platforms like Windows, Unix, Linux and various Unix derivatives. In addition to the server software, there are also client tools used for accessing and administering a directory server, Microsoft Office Active Directory Users and Computers or ADUC, which works well with Microsoft Active Directory Server. There are also other more open tools that can be used to interface with a lot of other directory server implementations. Along with clients for administering and managing a directory server, there are also client applications that can interface with and query a directory server. All major OS platforms support integrating into a directory server for log in and authentication purposes. The advantage here is that this allows for centralized management of user accounts. We'll cover the details of centralized management in the next lesson, so don't worry too much about that right now. When looking at specific implementations for your directory server, you'll want to consider OS support, not just the server they'll be running the directory service itself, but also what OS is your client fleet runs and the compatibility or support for you directory services. You can read more about why this is important in the next reading.

3. What is centralized management?

The job of the systems administrator is to, well, administer systems. Sysadmins have a set of systems they're responsible for. And they have to manage those systems so they're available to serve their function to the organization. For example, as a sysadmin, I might be responsible for making sure that all of the servers in my network are kept up to date with security patches and application updates. Should I go around and log into each server, checking each one at a time? What if I need to manage user accounts on end user devices? Should I go to each employee's desk and set their account up that way?

I guess I could, but that would be super time-consuming, and probably inconsistent. Instead, what I want to do is use centralized management, a central service that provides instructions to all of the different parts of my IT infrastructure. Directory services are one of these services. Remember in earlier lessons when you created accounts and gave them access to resources on your computer? Imagine that you worked for an organization that has dozens, hundreds, or even thousands of computers and people who use them. You can't possibly go into each of those computers to set them up. Directory services provides centralized authentication, authorization, and accounting, also known as AAA.

When computers and applications are configured to use directory services, or AAA services, decisions about granting or denying access to computers, file systems, and other IT resources are now centralized. Now you can create a user account once, and it's available for the entire network at once. Easy, well, sort of. You will learn a lot more about AAA services in an upcoming course. For now you should understand that your directory service will be responsible for granting or denying access to computers, file systems, and other IT resources. Now let's go one step further. Let's say you have a network file system that you need to give everyone in the IT department access to. You could set up the network share, then give it a list of user accounts to grant access to the share. But what happens when someone new joins the IT department? What about when someone leaves? Instead of granting access based on who you are, what if you granted access based on what you do? In most organizations, access to computer and network resources is based on your role in the organization. When you manage access to resources on a computer and on the network, you'll often grant and deny access based on user groups. User groups can be used to organize user accounts in all sorts of ways. You might create groups of buildings that people work out of, or the person's role in the organization, or really almost anything else.

What's important is that you use groups to organize accounts based on the way that you'll manage them. If you are a systems administrator, then you might have permission to do things like creating user accounts and resetting passwords. You are allowed to do that because of your role as a systems administrator. If you add another systems administrator to your organization, you don't want to have to find out all of the things that a sysadmin should have access to, then grant them individual account access to each of those resources. That would just take forever. Instead, we'll create a group of sysadmins and add all system administrators to that group. Then we can give the systems administrators' group access to any resources they need. If you or another person change roles in the company, then all you have to do is change the groups that you are a part of, not the rights that you have to directly access resources. We call this role-based access control, or RBAC.

Controlling access to resources isn't all you can do. You can also centralize configuration management. Just like you don't want to run around to every computer to configure user accounts, you wouldn't want to do that to setup printers, configure software, or mount network file systems. By centralizing the configuration management of your computers and software, you can create rules about how things should work in your organization. There are many ways to centralize your configuration management. And an easy way to get started is with as simple a tool as logon scripts that run each time someone logs on to a computer. Later in this module, we'll look at Active Directory and its group policy objects, which are a way to manage the configuration of Windows machines. There are also dedicated configuration management frameworks, like Chef, Puppet or SCCM, that can be used for super simple or super powerful configuration management. These are outside the scope of this module, so check out the supplemental reading

4. What is LDAP?

Before we jump into directory services, let's talk about the underlying protocol that's used in directory services called LDAP or lightweight directory access protocol. LDAP is used to access information in directory services like over a network. Two of the most popular directory services that use LDAP are active directory and openLDAP, which we'll talk about more in upcoming lessons. There are a lot of different operations you can use in LDAP. You can add a new entry in the directory server database like creating a new user objects called Cristi.

You can delete an entry in the directory server database. You can modify entries and much, much more. When we say entry, we're reffering to the LDAP entry format or LDAP notation for records in the directory service. An LDAP entry is just a collection of information that's used to describe something. Take a look at this example. Don't worry too much about what this says.

The format of LDAP entry basically has a unique entry name denoted by dn or distinguished name, then attributes and values associated with that entry. So, CN is the common name of the object. In this case, since it's a person, we use Devan Sri-Tharan as the name. OU is the organizational unit such as a group. And in this case, Sysadmin is used. DC is the main component. So example.com is split into example then com. Again, it's not necessary to remember these attributes. You can reference them in the next reading. The takeaway here is that LDAP notation is used for entries in directory services to describe attributes using values.

5 .What is LDAP Authentication?

If were around when phone books were used, you might remember that these big old books contained the names, addresses, and phone numbers of people in your neighborhood or community, who wanted the information to be publicly listed. This is way different from the phone book or contact list you have in your mobile phone.

The people who are in your contacts directory gave you their phone numbers for your use only. When using LDAP, there are different authentication levels that can be used to restrict access to certain directories, similar to those big public phone directories or those private mobile phone directories. Maybe you have a directory that you want to make public so anyone can read the entries in the directory or maybe you just want to keep that data private to only those who need it. We'll discuss how LDAP does this authentication and what methods it uses. We talked about the different operations you can do with LDAP, like add, remove or modify entries in a directory. Another operation that you can perform is the Bind operation, which authenticates clients to the directory server. Let's say you want to log in to a website that uses a directory service. You enter your account login information and password, your information is then sent back to the website.

It will use LDAP to check if that user account is a user at the directory and that the password is valid. If it's valid, then you will be granted access into that account. You want your data to be protected and encrypted when it's completing this process.

There are three common ways to authenticate. The first is anonymous, then simple, and the last is SASL, or simple authentication and security layer. When using anonymous binding, you aren't actually authenticating at all, depending on how it's configured anyone could potentially access that directory, just like our public phone book example. When you use simple authentication you just need the directory entry name and password, this is usually sent in plain text, meaning it's not secure at all. Another authentication method that's commonly used is SASL authentication. This method can employ the help of security protocols like TLS, which we've already learned about in Kerberos, which we'll discuss in a minute. SASL authentication requires the client and the directory server to authenticate using some method. One of the most common methods for this authentication is using Kerberos. Kerberos is a network authentication protocol that is used to authenticate user identity, secure the transfer of user credentials, and more. Kerberos by itself can be a complex topic that we'll revisit in the IT security course. If you want to learn more about Kerberos right now, you can check out at the supplemental reading right after this lesson. Once the client has successfully authenticated with LDAP server or directory service, the user will be authorized to use whatever access levels they have. In the next few lessons we're going to dive deeper into two of the most popular directory services that use LDAP, Active Directory and OpenLDAP.

6.What is Active Directory?

Welcome back. In this lesson, we'll learn more about Active Directory, or AD, the native directory service for Microsoft Windows. Active Directory has been used to centrally manage networks of computers since it was introduced with Windows Server 2000. If there are computers running Windows in your organization then AD probably plays a huge role.

Active Directory works in a similar fashion to open LDAP. It actually knows how to speak the LDAP protocol and can interoperate with LINUX, OS X, and other non-Windows hosts using that protocol.

When you use Active Directory to manage a fleet of Windows servers and client machines, it does a lot more then just provide directory services and centralized authentication. It also becomes the central repository of group policy objects, or GPOs, which are ways to manage the configuration of Windows machines. We'll show you how to do this later in this lesson. Now let's take a look at a typical Active Directory domain and see what it contains.

Active Directory Administration relies on a whole suite of tools and utilities. We're going to use a tool called the Active Directory Administrative Center, or ADAC.

ADAC is a tool that we'll use for lots of the everyday tasks that you'll learn in this course. It's great for getting work done, and for learning how things work behind the scenes, as you'll see.

Remember that, much like file systems, directory services are hierarchical.

Everything that you see in Active Directory is an object. Some objects are containers, which can contain other objects. Several of the default containers are just called containers, and they serve as default locations for certain types of objects. Another type of container is called an organizational unit, or OU, which we talked about in an earlier lesson. You can think of an OU like a folder or a directory for organizing objects within a centralized management system.

Ordinary containers can't contain other containers, but OUs can contain other OUs. That's a little confusing, so to show you the hierarchical structure of AD better, I've clicked this button of the left-hand pane to switch ADAC to tree view.

There are lots of things listed here. ADAC tells us what kind of object each of these are and gives us a description for some of them. We're not going to work with all of these, but we want to call out some parts of the directory that are more common to work with. The very first node in this tree is our domain. A domain will have a short name like example, and a DNS name like example.com. Objects, particularly computers in the domain, will be given a DNS name that lives in the domain's DNS zone. There's actually one level of hierarchy above a domain that we don't see in this tool, and that's a Forest.

If you look at the logical shape of a domain, it looks like a tree, so the name even makes sense. A forest contains one or more domains. Accounts can share resources between domains in the same forest. In our example environment, example.com is the only domain in the forest.

The next example that we'll look at is computers. This container is where new AD computer accounts are created. So if I go here, you can see my computers. Computer accounts are created when a computer is joined to the AD domain. The next thing that we'll look at is domain controllers.

![COMPUTERS].jpg](https://cdn.steemitimages.com/DQmfZ5ztbMcD2K7tQsPwcSPcrF6sBBpcyxCHmkfC5EaeCQJ/COMPUTERS].jpg)

This container is where domain controllers are created by default.

Next we'll look at users.

This container is where new AD users and groups are created by default. The service that hosts copies of the Active Directory database are called domain controllers, or DCs.

Domain controllers provide several services on the network. They host a replica of the Active Directory database and group policy objects. DCs also serve as DNS servers to provide name resolution and service discovery to clients. They provide central authentication through a network security protocol called Kerberos. As I mentioned, we'll talk more about Kerberos in the IT security course. For now, what you should understand is that domain controllers get to decide when computers and users can log onto the domain.

They also get to decide whether or not they have access to shared resources like file systems and printers. This allows system administrators to make changes to the network really quickly and easily. If someone new joins the organization, sys admins can create a user account for them, and almost immediately every device in the network knows who that person is.

If someone changes jobs in the org or leaves, a sys admin can disable or delete their account, and within seconds, their access to devices adjust. It's common for most domain controllers in the Active Directory network to be the read-write replicas. This means that each have a complete copy of the AD database and are able to make changes to it. Those changes are then replicated to all other copies of the data basis on other DCs. Replication is usually quick and the last change wins in almost all cases. This isn't perfect, but it works for most tasks. Some changes to the AD database can only be safely made by one DC at a time. We task those changes to a single domain controller by granting it a flexible single-master operations, or also known as FSMO role. We won't go into depth here on the nitty gritty details around what each of these FSMO roles are responsible for and how they operate, but you can check out the next reading for more. If your job will involve domain control and management, you'll need to understand how to assign FSMO roles and recover from DC failure. In order for computers to take advantage of the essential authentication services of AD, they have to be joined or bound to Active Directory. Joining a computer to Active Directory means two things. The first is that AD knows about the computer and has provisioned a computer account for it. The second is that the computer knows about the Active Directory domain and authenticates with it. From that point forward, the computer can authenticate to Active Directory just as any user who log onto the computers are able too.
For more information about Active Directory, check out the link here. https://technet.microsoft.com/en-us/library/cc961936.aspx

7. Managing Active Directory

Managing Active Directory isn't just a big topic, it's a huge topic. There are system administrators who spend all their time just managing AD. We're going to spend some time showing you some of the most common tasks that a sysadmin would need to do in an Active Directory environment. When an Active Directory domain is first set up, it contains a default user account, administrator, and several default user groups. Let's do a rundown of the most important groups. So, I want to first get into my Active Directory window. And as you can see, I'm an example.com. I'll run through the users. Domain admins are the administrators of the Active Directory domain. The Administrator account is the only member of this group in a new domain. Remember, how a local administrator or root on a computer is able to make any changes they want to the operating system. Users in the Domain Admins group can make any changes they want to the domain. Since a domain can control the configuration of all of the computers that are bound to it, domain admins can become local administrators of all of those machines too. This is a huge amount of power and responsibility. So don't add accounts to this group lightly. Enterprise Admins are administrators of the Active Directory domain. They also have a permission to make changes to the domain that affect other domains in multi-domain forest.

The administrator account is the only member of this group in a new domain. Enterprise Admin accounts should only be needed on a very occasion like when Active Directory Forest is being upgraded to a new version. Domain Users is a group that contains every user account in the domain. If you want to give access to a network resource to everyone in the domain, you don't need to grant access to every individual account. You can use to Domain Users. Each computer that's joined to the domain has an account too. So, we have a default group for them also. Domain Computers contains all computers joined to the domain except domain controllers. Domain Controllers contains all domain controllers in the domain. I'm going to be able to do everything in this lesson because I'll be playing the role of a domain admin in my example organization. As a systems administrator, or IT support specialist, you might also be a domain admin or enterprise admin because of the power they give you to make changes in Active Directory. You should never use a domain admin account as your day to day user account. It's too easy to make a mistake that affects the entire organization. Domain admin accounts should only be used when you deliberately making changes to Active Directory. Got it? Your normal user account should be very much like other user accounts in the domain, where your permissions are restricted just to those resources that you need to have access to all the time. If there are some administrative tasks that you need to perform a lot as a part of your day to day job but you don't need to have broad access to make changes in AD, then delegation is for you. Just like you can set NTFS DACLs to give accounts permission in the file system. You can set up ACLs on Active Directory objects. If you'd like to learn more about this, more advanced topic, check out the next reading. Let's start administering Active Directory. First up, we'll take a look at user account administration.

For Part 2 Click Here ----------------------

To Join this course click on the link below

Google IT Support Professional Certificate http://bit.ly/2JONxKk

LInks to previous weeks Courses.

[Week 3] Google IT Support Professional Certificate #24 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2BRtOLu
[Week 2] Google IT Support Professional Certificate #23 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2N25GqA

[Week 1] Google IT Support Professional Certificate #22 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2PiJpX2
[Week 6] Google IT Support Professional Certificate #21 | Course 4 System Administration and IT Infrastructure Services
http://bit.ly/2MqF857
[Week 5] Google IT Support Professional Certificate #20 | Course 3 WEEK 5 Operating Systems and You: Becoming a Power User
http://bit.ly/2P8wVRQ

[Week 4] Google IT Support Professional Certificate #19 || Course 3 WEEK 4 Operating Systems and You: Becoming a Power User
http://bit.ly/2B6KE8E

[Week 3] Google IT Support Professional Certificate #17 || Course 3 WEEK 3 Operating Systems and You: Becoming a Power User{Part 1}
http://bit.ly/2AYxJ8Z

[Week 2] Google IT Support Professional Certificate #16 || Course 3 WEEK 2 Operating Systems and You: Becoming a Power User
http://bit.ly/2nhSKBA

[Week 1] Google IT Support Professional Certificate #15 || Course 3 WEEK 1 Operating Systems and You: Becoming a Power User {Part 2}
http://bit.ly/2naOweX

[Week 1] Google IT Support Professional Certificate #14 || Course 3 WEEK 1 Operating Systems and You: Becoming a Power User {Part 1}
http://bit.ly/2M4pn3C

Google IT Support Professional Certificate #0 | Why you should do this Course? | All details before you join this course.
http://bit.ly/2Oe2t8p

#steemiteducation #Computerscience #education #Growwithgoogle #ITskills #systemadministration #itprofessional
#googleitsupportprofessional

Atlast If you are interested in the IT field, this course, or want to learn Computer Science. If you want to know whats in this course, what skills I learned Follow me @hungryengine. I will guide you through every step of this course and share my knowledge from this course daily.

Support me on this journey and I will always provide you with some of the best career knowledge in Computer Science field.