1
00:00:00,000 --> 00:00:18,080
Hey everyone and welcome back. So in this nugget right here what we're going to do is

2
00:00:18,080 --> 00:00:22,960
we're going to change gear a little bit and we're going to focus on something called LDAP.

3
00:00:22,960 --> 00:00:29,519
Now LDAP is the lightweight directory access protocol and ultimately what this is going

4
00:00:29,519 --> 00:00:36,640
to do is going to provide to us a distributed directory service. Now LDAP is a protocol

5
00:00:37,200 --> 00:00:43,439
that works in Windows. If you've ever heard of something called Active Directory which is very

6
00:00:43,439 --> 00:00:50,399
very common in the enterprise world. Active Directory is going to use heavily the LDAP protocol.

7
00:00:50,399 --> 00:00:57,280
Now specifically for us on Linux we're going to be using something called Open LDAP. This is the

8
00:00:57,280 --> 00:01:02,960
version of LDAP that is going to be operational on our Linux based systems. So really when we're

9
00:01:02,960 --> 00:01:09,920
talking about LDAP we are talking about a directory like structure. So you could imagine

10
00:01:09,920 --> 00:01:15,840
you know the way you can use a phone book back in the day whereby you could look up a business

11
00:01:15,840 --> 00:01:21,520
name and correlate that to say for example a phone number or perhaps an address whatever it may be.

12
00:01:21,519 --> 00:01:27,519
This is a collection of data that is easily searchable and accessible. Ultimately this is what

13
00:01:27,519 --> 00:01:34,319
we're going to be doing here with respect to LDAP. Instead though with LDAP though what we're going to

14
00:01:34,319 --> 00:01:40,640
do is we're going to store information relating to our users and we're going to use this information

15
00:01:40,640 --> 00:01:48,079
about your users to control the authentication process. So really we could have a large organization

16
00:01:48,079 --> 00:01:54,400
with thousands of users all of which their details are going to be known and stored within

17
00:01:54,400 --> 00:02:02,640
the LDAP directory so that when a user tries to log in we consult the LDAP server and the LDAP

18
00:02:02,640 --> 00:02:09,199
server can authenticate this user and not just allow them to log in provide to them the environment

19
00:02:09,199 --> 00:02:15,439
that should be associated with that user i.e. what group do they belong to? Are they in the marketing

20
00:02:15,439 --> 00:02:21,039
department? Are they in the financial department? Maybe they're in the design department so things

21
00:02:21,039 --> 00:02:27,039
like their role in the organization we can also provide the correct home directories that should

22
00:02:27,039 --> 00:02:34,400
be associated with this user. All of this is made possible and at scale using LDAP. Now before we

23
00:02:34,400 --> 00:02:40,639
actually kick off and look at the details here there is some terminology that we absolutely

24
00:02:40,639 --> 00:02:46,000
have to be aware of. The very first thing we want to know is that with respect to LDAP we have

25
00:02:46,000 --> 00:02:52,559
something called an object. Now you can conceptualize an object as a record and this is going to be a

26
00:02:52,559 --> 00:02:59,439
single record within the directory so this could be a particular user account or perhaps a particular

27
00:02:59,439 --> 00:03:06,959
machine on the network maybe a printer. An object is one of the key features of LDAP. Now once we

28
00:03:06,960 --> 00:03:14,960
have established an object such as maybe a user the next term you want to know is the attribute

29
00:03:14,960 --> 00:03:22,560
term. Now all the attribute term relates to are the attributes associated with the objects okay so

30
00:03:22,560 --> 00:03:29,360
we have objects and those objects have particular attributes so if you happen to have a user on

31
00:03:29,360 --> 00:03:36,879
the system maybe their unique identifier would be a particular attribute of that object or if you had

32
00:03:36,960 --> 00:03:45,280
a group object the group ID could be an attribute of that object. Now the way these objects and

33
00:03:45,280 --> 00:03:52,000
attributes happen to be structured and defined this is in accordance with what is called the schema.

34
00:03:52,000 --> 00:03:58,560
So the schema could define the type of objects we could have. We could have say for example a person

35
00:03:58,560 --> 00:04:06,159
and the schema says that this particular object can have particular attributes things like a surname

36
00:04:06,159 --> 00:04:12,400
or things like I say a UID so the UID and the surname would be an attribute of the object but

37
00:04:12,400 --> 00:04:19,199
the actual structure here i.e. that we can have a person and that object will have these particular

38
00:04:19,199 --> 00:04:26,959
attributes is defined in the schema so check this out with respect to our LDAP service this is going

39
00:04:26,959 --> 00:04:33,920
to be structured in a very hierarchical manner going to follow a particular hierarchy. So let's

40
00:04:33,920 --> 00:04:41,520
pretend that I happen to own the domain ipv0.com I don't actually own this but let's just pretend

41
00:04:41,520 --> 00:04:49,840
and let's imagine that ipv0 was a huge huge company within this company we may have an IT department

42
00:04:49,840 --> 00:04:56,639
we may have a finance department and then within the IT department we may have particular users

43
00:04:56,639 --> 00:05:03,759
and the users in that department could be say for example John and Trevor and the finance department

44
00:05:03,759 --> 00:05:10,319
they also may have users of the system so let's maybe say we've got Lauren and Brian now notice

45
00:05:10,319 --> 00:05:19,759
the way that the organization here has a natural hierarchy we all belong to ipv0.com within ipv0

46
00:05:19,759 --> 00:05:24,959
we have particular departments and those departments may have users and they may have particular groups

47
00:05:24,959 --> 00:05:30,800
whatever it may be and within those users we have people like John and people like Trevor and at the

48
00:05:30,800 --> 00:05:36,000
same time we also have another department which acts as a container for different users such as

49
00:05:36,000 --> 00:05:41,680
Lauren and Brian this is ultimately just a hierarchy and this is what we're going to be constructing

50
00:05:41,680 --> 00:05:48,480
when we use our LDAP service so let's use this example again ipv0.com this is the way this is

51
00:05:48,480 --> 00:05:53,840
going to shake out now we're going to talk about a few particular terms here so we're going to have

52
00:05:53,919 --> 00:06:01,679
something called a DC this is a directory container so this could be your domain name or the name of

53
00:06:01,679 --> 00:06:08,159
your database so what we would do is we would take our domain name and we're going to split it up

54
00:06:08,159 --> 00:06:15,359
and at the very end this is going to be our very first directory container so we would have a COM

55
00:06:15,359 --> 00:06:23,039
DC and then within that we would have an ipv0 DC now within here we can go about

56
00:06:23,120 --> 00:06:29,280
constructing many different elements one foundational element of LDAP is something called

57
00:06:29,280 --> 00:06:35,360
an organizational unit now an organizational unit you can conceptualize this as a flexible type of

58
00:06:35,360 --> 00:06:41,200
container flexible in that you can use it for many different things you can use it for organizing

59
00:06:41,200 --> 00:06:48,240
groups or users or admins whatever it may be so in the previous example we had a finance department

60
00:06:48,240 --> 00:06:54,160
and an IT department so we could have a finance organizational unit which would act as a container

61
00:06:54,160 --> 00:07:00,639
for perhaps users and groups and within those users and groups they could also be organizational

62
00:07:00,639 --> 00:07:06,879
units that contain users of that particular department so on so forth so we could then do

63
00:07:06,879 --> 00:07:13,280
so this can be our DC and our DC and let's go with the same example let's say we wanted to

64
00:07:13,279 --> 00:07:18,319
split up our organization into department again this would be a completely arbitrary choice

65
00:07:18,319 --> 00:07:24,079
so let's just say we have a human resources department and a sales department and a marketing

66
00:07:24,079 --> 00:07:30,559
department and again emphasis on the flexibility here and these would all be organizational units

67
00:07:30,559 --> 00:07:36,879
all use all of these here and emphasis again on the flexibility there is nothing particular about

68
00:07:36,879 --> 00:07:44,480
this naming convention it's purely my own design I'm choosing to organize my data in this way via

69
00:07:44,480 --> 00:07:50,159
particular departments so let's say that within these organizational units we just directly started

70
00:07:50,159 --> 00:07:57,360
adding users okay so we could have John and HR department as well as Trevor and then in the

71
00:07:57,360 --> 00:08:04,079
sales department we could have Bob and in the marketing department we could have Nox and Keith

72
00:08:04,079 --> 00:08:11,279
now each of these objects here you would assign particular attributes based on the schema now

73
00:08:11,279 --> 00:08:17,279
whilst we have mentioned the DC the directory container as well as the OU the organizational

74
00:08:17,279 --> 00:08:22,560
unit the next thing I really want to hone in is something called a DN now I know this can be

75
00:08:22,560 --> 00:08:27,839
confusing DCs and DNs and OUs this is again something that just syncs in with a little bit

76
00:08:27,839 --> 00:08:34,879
of familiarity in practice so try not to be overwhelmed here so a DN is called the distinguished

77
00:08:34,879 --> 00:08:40,000
name we really want to be remembering this okay now the distinguished name this is how you're going

78
00:08:40,000 --> 00:08:47,279
to uniquely identify a particular object within the directory now the way the DN is actually

79
00:08:47,279 --> 00:08:54,319
constructed is you effectively just walk your way back up through the hierarchy so say for example

80
00:08:54,320 --> 00:09:00,960
John would have to have a particular attribute such as a UID as per the schema let's say that

81
00:09:00,960 --> 00:09:08,080
would be John's UID we can see here John is part of the organizational unit called HR and we can see

82
00:09:08,080 --> 00:09:18,720
the directory containers which John belongs to is IPv0 so say DC IPv0 and that also is within a DC

83
00:09:18,720 --> 00:09:26,399
called COM so DC COM so all this information here although it might be confusing this all together

84
00:09:26,399 --> 00:09:34,080
is the distinguished name that uniquely identifies this particular object within the directory tree

85
00:09:34,080 --> 00:09:41,360
so really the distinguished name is completely unambiguous it is very explicit and it's meant to

86
00:09:41,360 --> 00:09:47,360
prevent any type of confusion because let's say you maybe have a user of a particular name and also

87
00:09:47,360 --> 00:09:53,440
somewhere else within the directory tree structure we have another group which has the same name we

88
00:09:53,440 --> 00:09:59,279
do not want to have any point of confusion we could still uniquely identify the particular object

89
00:09:59,279 --> 00:10:04,159
by following this tree structure using the distinguished name which will just precisely

90
00:10:04,159 --> 00:10:09,440
point out that exact object now one thing we want to be aware of for the purposes of the examination

91
00:10:09,440 --> 00:10:14,560
and we don't have to see this in any real detail at all is we want to be aware of something called

92
00:10:14,639 --> 00:10:25,519
SSSD what this is is the security system services daemon now the SSSD is what can be used to provide

93
00:10:25,519 --> 00:10:30,559
the actual authentication itself so we really don't have to worry about how this actually works

94
00:10:30,559 --> 00:10:37,279
in the examination we just want to know that LDAP leverages SSSD for the actual authentication going

95
00:10:37,279 --> 00:10:43,039
on here so now that we have a rough idea of what LDAP actually is it is ultimately a directory

96
00:10:43,039 --> 00:10:49,679
tree like structure and we have these particular terms how about we actually dive in to some LDAP

97
00:10:49,679 --> 00:10:53,919
configuration and well that's what we'll be doing in the very next nuggets I hope this has been

98
00:10:53,919 --> 00:10:56,879
informative for you and I'd like to thank you for viewing

