Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
Lelio, We worked around this by never assigning DNs in UCM. We only assign ipPhone in AD. Then, our UCM filter only matches users with ipPhone. So the typical process for a new user is to modify the user's ipPhone, then run UCM sync, then self provision. Not too bad. -- Hunter Fuller Router Jockey VBH Annex B-5 +1 256 824 5331 Office of Information Technology The University of Alabama in Huntsville Network Engineering On Thu, Jan 30, 2020 at 5:44 PM Lelio Fulgenzi wrote: > > Using the ipPhone field is an option. However, it’s a bit of a chicken and > egg thing. They don’t have an extension until we assign it. And we can’t > import them until they have the number in that field. > > > > So we’d have to assign them an extension, modify the attribute, then sync > manually, then import, etc. > > > > There are some other scenarios which still wouldn’t help though. > > > > It’s a drag. ☹ > > > > But I’m still not defeated! > > > > From: Hunter Fuller > Sent: Thursday, January 30, 2020 6:26 PM > To: Lelio Fulgenzi > Cc: Charles Goldsmith ; voyp list, cisco-voip > (cisco-voip@puck.nether.net) > Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything > else other than SN=* (non-empty) ? > > > > On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi wrote: > > We can’t filter on anything telephone number based. Sounds silly, but the > information in the directory doesn’t always jive with what someone wants, > extension wise. > > > > This was true for us. Our solution was to populate the ipPhone field with > their real phone number and populate telephoneNumber with what they wanted to > appear in the directory (e.g., their admin assistant, or for some people in > IT it's the help desk, etc. etc.). Then UCM/Unity use the ipPhone attribute > for provisioning and all is well in the world. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
We also map mail to directoryURI , and enable IM&P automatically, so I added a concat (&(mail=*)) to ensure we don’t sync people without a URI. From: cisco-voip On Behalf Of Lelio Fulgenzi Sent: Thursday, January 30, 2020 6:45 PM To: Hunter Fuller Cc: Charles Goldsmith ; voyp list, cisco-voip (cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? Using the ipPhone field is an option. However, it’s a bit of a chicken and egg thing. They don’t have an extension until we assign it. And we can’t import them until they have the number in that field. So we’d have to assign them an extension, modify the attribute, then sync manually, then import, etc. There are some other scenarios which still wouldn’t help though. It’s a drag. ☹ But I’m still not defeated! From: Hunter Fuller mailto:hf0...@uah.edu>> Sent: Thursday, January 30, 2020 6:26 PM To: Lelio Fulgenzi mailto:le...@uoguelph.ca>> Cc: Charles Goldsmith mailto:w...@woka.us>>; voyp list, cisco-voip (cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net>) mailto:cisco-voip@puck.nether.net>> Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi mailto:le...@uoguelph.ca>> wrote: We can’t filter on anything telephone number based. Sounds silly, but the information in the directory doesn’t always jive with what someone wants, extension wise. This was true for us. Our solution was to populate the ipPhone field with their real phone number and populate telephoneNumber with what they wanted to appear in the directory (e.g., their admin assistant, or for some people in IT it's the help desk, etc. etc.). Then UCM/Unity use the ipPhone attribute for provisioning and all is well in the world. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
Using the ipPhone field is an option. However, it’s a bit of a chicken and egg thing. They don’t have an extension until we assign it. And we can’t import them until they have the number in that field. So we’d have to assign them an extension, modify the attribute, then sync manually, then import, etc. There are some other scenarios which still wouldn’t help though. It’s a drag. ☹ But I’m still not defeated! From: Hunter Fuller Sent: Thursday, January 30, 2020 6:26 PM To: Lelio Fulgenzi Cc: Charles Goldsmith ; voyp list, cisco-voip (cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi mailto:le...@uoguelph.ca>> wrote: We can’t filter on anything telephone number based. Sounds silly, but the information in the directory doesn’t always jive with what someone wants, extension wise. This was true for us. Our solution was to populate the ipPhone field with their real phone number and populate telephoneNumber with what they wanted to appear in the directory (e.g., their admin assistant, or for some people in IT it's the help desk, etc. etc.). Then UCM/Unity use the ipPhone attribute for provisioning and all is well in the world. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
On Thu, Jan 30, 2020 at 4:51 PM Lelio Fulgenzi wrote: > We can’t filter on anything telephone number based. Sounds silly, but the > information in the directory doesn’t always jive with what someone wants, > extension wise. > This was true for us. Our solution was to populate the ipPhone field with their real phone number and populate telephoneNumber with what they wanted to appear in the directory (e.g., their admin assistant, or for some people in IT it's the help desk, etc. etc.). Then UCM/Unity use the ipPhone attribute for provisioning and all is well in the world. ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
We can’t filter on anything telephone number based. Sounds silly, but the information in the directory doesn’t always jive with what someone wants, extension wise. That being said, I took the CUCM docs to heart and made sure to add the default filter they use but don’t show…. (&(objectclass=user)(!(objectclass=Computer))(!(UserAccountControl:1.2.840.113556.1.4.803:=2))) And then I added my “exclusion” group. My testing is being done on my test server, which isn’t complaining I just found out, like my production. Will have to look a bit deeper. In the mean time, looking at test unity server, which _was_ complaining. 😊 From: Charles Goldsmith Sent: Thursday, January 30, 2020 5:41 PM To: Lelio Fulgenzi Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? This is what I recommend to customers, users, not pc's and the ipPhone field is populated. (&(objectclass=user)(!(objectclass=Computer))(ipPhone=*)) On Thu, Jan 30, 2020 at 3:34 PM Lelio Fulgenzi mailto:le...@uoguelph.ca>> wrote: OK - I'm trying to reconcile accounts being imported into CUCM before I modify the filter we're using. I've used the base filter suggested, plus I've added the (sn=*) to ensure we get only accounts with non-empty last names. However, my reconciliation is off by 1 (including taking into account inactive LDAP accounts). CUCM: 86,636 LDAP Browser: 86,637 I could just write it off as an anomaly, but I've sync'ed multiple times and ran the LDAP search multiple times, and I'm pretty sure no one is making changes. Anyone aware of any other criteria CUCM puts on to the import process? ___ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
This is what I recommend to customers, users, not pc's and the ipPhone field is populated. (&(objectclass=user)(!(objectclass=Computer))(ipPhone=*)) On Thu, Jan 30, 2020 at 3:34 PM Lelio Fulgenzi wrote: > > OK - I'm trying to reconcile accounts being imported into CUCM before I > modify the filter we're using. > > I've used the base filter suggested, plus I've added the (sn=*) to ensure > we get only accounts with non-empty last names. > > However, my reconciliation is off by 1 (including taking into account > inactive LDAP accounts). > > CUCM: 86,636 > LDAP Browser: 86,637 > > I could just write it off as an anomaly, but I've sync'ed multiple times > and ran the LDAP search multiple times, and I'm pretty sure no one is > making changes. > > Anyone aware of any other criteria CUCM puts on to the import process? > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
OK. My reconcile was off by more…. The numbers were off by one. This stems from getting errors from unity trying to sync more than one account with the same email address. We have a process issue that needs to be corrected, but it takes time each time this crops up. When I searched for the two problem accounts in CUCM, they didn’t exist at all. So CUCM doesn’t seem to throw an error, it just ignores it. *scratches head* Going to go ahead with the filter as is on CUCM and see the results, then apply to Unity. (all in dev servers first). Wish me luck! From: Anthony Holloway Sent: Thursday, January 30, 2020 5:08 PM To: Lelio Fulgenzi Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) Subject: Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ? I think you understand it correctly. Unless we're both wrong. Are you using the same filter in both CUCM as the LDAP browser (can you share it?)? Same search base? Same user to BIND with? Same AD or GC server? Same Port? Same TLS setting? Do you know which user account is the anomaly? On Thu, Jan 30, 2020 at 3:34 PM Lelio Fulgenzi mailto:le...@uoguelph.ca>> wrote: OK - I'm trying to reconcile accounts being imported into CUCM before I modify the filter we're using. I've used the base filter suggested, plus I've added the (sn=*) to ensure we get only accounts with non-empty last names. However, my reconciliation is off by 1 (including taking into account inactive LDAP accounts). CUCM: 86,636 LDAP Browser: 86,637 I could just write it off as an anomaly, but I've sync'ed multiple times and ran the LDAP search multiple times, and I'm pretty sure no one is making changes. Anyone aware of any other criteria CUCM puts on to the import process? ___ cisco-voip mailing list cisco-voip@puck.nether.net<mailto:cisco-voip@puck.nether.net> https://puck.nether.net/mailman/listinfo/cisco-voip ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
Re: [cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
I think you understand it correctly. Unless we're both wrong. Are you using the same filter in both CUCM as the LDAP browser (can you share it?)? Same search base? Same user to BIND with? Same AD or GC server? Same Port? Same TLS setting? Do you know which user account is the anomaly? On Thu, Jan 30, 2020 at 3:34 PM Lelio Fulgenzi wrote: > > OK - I'm trying to reconcile accounts being imported into CUCM before I > modify the filter we're using. > > I've used the base filter suggested, plus I've added the (sn=*) to ensure > we get only accounts with non-empty last names. > > However, my reconciliation is off by 1 (including taking into account > inactive LDAP accounts). > > CUCM: 86,636 > LDAP Browser: 86,637 > > I could just write it off as an anomaly, but I've sync'ed multiple times > and ran the LDAP search multiple times, and I'm pretty sure no one is > making changes. > > Anyone aware of any other criteria CUCM puts on to the import process? > ___ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > ___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
[cisco-voip] CUCM requirements for AD account import - anything else other than SN=* (non-empty) ?
OK - I'm trying to reconcile accounts being imported into CUCM before I modify the filter we're using. I've used the base filter suggested, plus I've added the (sn=*) to ensure we get only accounts with non-empty last names. However, my reconciliation is off by 1 (including taking into account inactive LDAP accounts). CUCM: 86,636 LDAP Browser: 86,637 I could just write it off as an anomaly, but I've sync'ed multiple times and ran the LDAP search multiple times, and I'm pretty sure no one is making changes. Anyone aware of any other criteria CUCM puts on to the import process? <>___ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip
