We have several ways to add users. One-by-one, the Bulk Administration Tool or an LDAP integration with the Communications Manager. And within that LDAP external directory we have a couple of options. We can say we want to just synchronize these end users or we can say synchronization and authentication. So when we use LDAP, some user data is no longer controlled via the Communications Manager Express administration. PINs, for example, specific to your IP phones are going to be managed by the Communications Manager Solution, but a username and password, we actually have an option whether we manage it locally or we offload that to active directory, as an example. If you run active directory, that’s an LDAP compliant database, and now active directory, if we have authentication set in place, can manage the username and passwords.
Within our end-user accounts there are mandatory attributes and optional attributes. Mandatory – user ID and last name. So if you looked at the config file for this or the administrative GUI for this you would see the little asterisk (*) after those two fields. Optionally, we have first name, middle name, telephone numbers – these are optional fields and if we don’t populate them they are just left blank and that’s okay. When we synchronize with an external LDAP directory the mandatory attributes have to be populated. So if you’re having problems synchronizing there might be something wrong with those attributes not being able to be pulled in, so it fails. Optional parameters – doesn’t matter, they’re just going to be missing from the fields and maybe we need to use BAT to go in and do some population or go in and tweak a couple of the user accounts that may be missing some information.
We’ll now look at each type of way to add our end users. First of all, manually, you’ll go into your User Management > End User Configuration page and you’ll configure the user ID, password and PIN and then whatever device you’re going to associate with this particular user account.
We can put in things like the telephone number and a lot of different manager fields. There is a lot of different attributes within this configuration page and this is great when you don’t have to add a lot of people. This is probably not going to work well if you have 10,000 users. I don’t want to see you out there one-by-one adding these users hopefully you can tie into an LDAP compliant database.
With the Lightweight Directory Access Protocol or LDAP it needs to be Version 3. This is what you can tie into and there are several different databases. I pick on active directory because I’m familiar with it, but you also have Netscape, iPlanet, SunOne – all of those are LDAP compliant directories that you could tie into. You can pull in the user accounts and we have again two options on how to do this. We can pull in that user information one time, so let’s say the active directory folks created all user accounts for us, we just pull them in and now we manage them locally. Or we could go and set up the authentication process of all of this and say, “hey, you know what, we’re going to let you worry about username and passwords in that LDAP compliant database we’re just going to manage telephony specific options, like your PIN”, that would be managed locally. And all of this is just a way of managing large environments when you can tie into LDAP. It doesn’t mean you can’t do it in a small environment but I’m just thinking that, if I had to add even a 1,000 users that’s going to take a considerable amount of time. If I could just synchronize with an LDAP compliant database to pull these guys in then just think about it, I can use other tools like BAT to make changes if I needed to but now I’ve got all the records typed out and I can manage it so much easier than if I have to type them all in myself.
If we choose that option, users are added or deleted in the LDAP directory. Here’s the big “gotcha”, don’t go into the Communications Manager Administration page and delete or add users at that point. That will make a nightmare, plus you’ll be restricted from doing it to a degree, but it will create a nightmare for you because they won’t be in sync. All personal and organizational user data is configured in the LDAP database and that is replicated from the LDAP server to your Communications Manager, it’s read-only in the Communications Manager Administrative page. We kind of protect ourselves from ourselves of trying to delete or add a user when we’re synchronizing. User passwords and the Communications Manager settings are still configured from within the Communications Manager Administrative page. They are not configured in LDAP. I know I’ve mentioned this but we’ll see when there is a case that they could be managed from that LDAP directory. But for now all we’re talking about is synchronization. And with synchronization, because things change, you may want to make sure that the synchronization happens after your active directory solution has been modified or updated. Your active directory administrators may tell you that once a week maybe all of your active directory servers are synchronized and maybe after that synchronization takes place you should then resynchronize with their database to get the current information because if they add a user or delete a user you may want to continue maintaining that synchronization process so you get all the current information.
With LDAP you get that centralized user account repository and kind of you offload it from you having to manually add all these users. And the management of your user account of course is all managed with the LDAP directory and when we have synchronization enabled, the local directory database is still used because its replicated from LDAP and it’s using DirSync, that’s the process that it uses. And application users again are not synchronized because they’re not end users, they have a different entity, they have different attributes so we’re going to manage them, but we want to make sure that the LDAP synchronization does take place when it should. In other words if it needs to be scheduled once a week, once a day, whatever the case may be you want to double check and make sure that you’re getting the greatest and latest information from that LDAP server. So you want to check with those administrators and find out when that synchronization on their end takes place and then you can grab that information into the Communications Manager.
When we use an LDAP integration we can specify that we want to use authentication for our end users. Here is the low-down – of course the user has to exist in the LDAP directory for this to take place. LDAP synchronization is not mandatory but highly recommended. If you’re going to have this external LDAP compliant server manage your user authentication, then I think you want to have everything synchronized. I wouldn’t even call this non-mandatory, I would say synchronization and authentication go hand in hand. The user passwords are now configured and stored in LDAP so that means you’ve offloaded some of that management to your LDAP directory managers. So if I am a user and I log into my user web page, the username and password that I’m choosing to use here is the same password that I’m using to log into my computers, especially if I’m using like active directory. So what does that mean as far as password management, it means that I have to change the password in my log in credentials that I use on my PC or my laptop. In other words when I log in and I’m prompted to change that password on the computer that’s where I do it – cannot do it in my user web pages that help me manage my phone. If we think about it, it’d be kind of a security risk too to let a third-party application manage and change password in an external LDAP environment. So you have to train the users, your password modifications take place when you log into your computers and active directory or SunOne is managing that account. That same account is the account used to manage that user web page. So if user authentication is performed against that LDAP directory, it fails if the LDAP directory is not accessible.
LDAP authentication again is managed through that third-party LDAP server. And if LDAP sync is not used you have to have a identical user account created within the Communications Manager and it has to match up specifically, exactly with that account in that LDAP server. Now some things are still managed by the Communications Manager, we don’t go in and modify in other words the third-party LDAP database to store our pins. The pins will then be managed locally and of course application users again they may mention that they do not use LDAP authentication. So all of their username password management is all going to be done locally through our graphical user interface for the Communications Manager.
Here is a nice chart that’s showing us who is managing the data, where is it stored.
If we have no LDAP integration, basically we create a local database in the Communications Manager. If we do LDAP sync then it’s replicated to our local machine. If we do authentication then we have, remember we want to do synchronization so we want to replicate and we want to make sure that our local information is current and up-to-date. Again password and username management though is done through that third-party server. And when we compare this side-by-side it’s kind of good to know what settings are going to be managed locally within the Communications Manager. So in other words, if I took LDAP authentication and synchronization I’m using that – what’s stored locally? Well the PIN, any digest credentials, groups and roles, any of the associated devices that I’m managing, extension mobility profiles, my security settings that’s what CAPF is all about and any presence group and mobility information, because that’s specific, if we think about it, specific to the telecommunications environment and we’re not modifying that external LDAP server so that it now contains these extra fields. So we manage this locally or it’s stored locally on the Communications Manager.
So how do we map those attributes? Well we see that what we might choose could be let’s say the sAMAccount name for example. That data of that directory attribute is mapped to the Communications Manager user ID. And of course it has to be unique that’s why I chose the sAMAccount because that sAMAccount is unique within active directory, there are no duplicates. So we’re going to map that to the Communications Manager user ID. So that sn attribute is the last name and it must be populated with data otherwise that record will not be imported. Remember the last name that was a asterisk field within the configuration and if the primary attribute used during import of those end user accounts matches an application user it’s skipped because we don’t want to destroy our application users. And some of our Communications Manager database fields provide a choice of directory attributes, it’s only going to choose a single mapping for each field. So you may not see some of those choices selected appropriately.
I’ve mentioned a few times when we do this synchronization we want to make sure we do it again so that we keep up-to-date. We’re going to use this DirSync, that’s going to be enabled and that’s going to allow us to have one or more synchronization agreements. So we can go out and we can configure when we want this to happen. In other words we don’t have to do this in the middle of the day and bog the network down with all this traffic. We may want to do this in the wee hours of the morning so that we aren’t sending all that traffic down the path mid-day. And this agreement specifies a search base – why is that important? Active directory can be huge. It’s a forest with lots of trees and domain controllers and so we can specifically say where it is we want to synchronize these users from. And so that way maybe there is an area of users that we don’t manage on our telecommunication solution, well we don’t have to point to them, we don’t have to have them be part of this, we can just synchronize with the specific area of the domain that we want to have pulled into our system. That search base does not have to have or not have to specify the domain root, it’s one of the key terms in active directory and that search base can specify any point in the tree. It’s kind of the structure of the active directory – we have trees, we have domains and we have roots and we can specify where we want to set up that search agreement.
With synchronization we probably want to make sure we specify the time for this to begin and any reoccurrence that we want to take place. We can also set it up to just run once and if we do it the very first time there are some things that we need to be aware of. If we had created any end users they kind of become deactivated. LDAP end user accounts that exist in the Communications Manager database that are now deactivated are then activated and settings are updated if they match up and if they’re different in the LDAP server. LDAP end user accounts they are added to the Communications Manager and any deactivated accounts are purged from the Communications Manager database after 24 hours. It’s kind of like a time to live and time for everything to kind of synchronize, instead of just immediately deactivating that account. That could cause some issues in the synchronization of all of your users. So 24 hours later that’s when you’ll see those accounts disappear.
These are the best CCNA training resources online:
