Monday, July 18, 2022

Add Stern Insider Connected to your iPhone Home Screen

 Want to have your Stern Insider connected QR code handy on your iPhone but don't want it too intrusive?  How about having it as a simple Home Screen icon you can open with a single click, or even open via Siri?  Here's an idiots guide on how make that happen using Apple's Shortcuts.

This is as documented with Apple iOS 15.5

Update: An alternative is to use this shortcut which pops up a notification that you can click and hold to preview your QR image.  This method takes more clicks, but is a bit more responsive.  Open the link from your iPhone and it can be immediately added to your device.

1. Get your QR code as a photo on your phone with a known name

- Open the Inside Connected Website on your iPhone and view your QR Code

- Create a screenshot with the volume+power button shortcut.  I recommend editing the photo, zooming in and cropping it so the QR code is sufficiently large (about 1" wide) before saving the screenshot to your Photos.  

- Open your Photos app and locate your new QR photo.  Click it to open the photo and click the information icon (the 'i' icon) to see the photo's details.  Note the image's name.  Example: IMG_2886

2. Open the Apple Shortcut's app

- Browse or search for the app named Shortcuts on your phone.  If you have not used it before, you will have to download it form the app store.  It is an app from Apple.  Download and open the app

3. Create a new shortcut for your QR code

- Click the + icon at the top of the screen to create a new Shortcut.  An empty shortcut is started with tips on what to add


- Add a Find Photos action.  In the Search for apps and actions search field at the bottom of the screen, type the word Find and click on Find Photos in the search results.  This will add a new Find Photos action to your shortcut



- In the new Find Photo action, click the Add Filter link.  A default filter value is added which needs to be edited.  Click on each word to edit its value.  Change first word to Name.  Change the second word to is.  Change third word to the name of your screenshot photo you made in step 1.  THIS NAME IS CASE SENSITIVE!  Should look like this afterwards



- Add a Quick Look Action.  In the Search for apps and actions search field at the bottom of the screen, enter the text Quick and click on Quick Look in the search results.  This will add a new Quick Look action to your shortcut

4. Test your shortcut

- Click the play icon at the bottom of the screen to test your shortcut.  It will take 3-4 seconds then your QR code should show in a preview.  Click Done to return to your shortcut.  If it doesn't open, double check your Filter definition in the Find Photo action.  Your shortcut should look like this, with the name edited to whatever the name is for your photo.  This name is case sensitive!

Actions Added to Shortcut

5. Name and save your shortcut

- Click on the field at the top of the screen to name your shortcut.  Example: Show Stern Insider - This name can be used with Siri to call the shortcut.


=

- Click on the settings icon to the right of the name

- Click Add to Home Screen to add the shortcut to your home screen

- You can customize the icon and name for the shortcut as shown on the screen.  Click on the icon to change it to a photo of your choice, and click on the name and customize to something short like "Stern IC"

- Click Add to save the changes

Complete!  Your shortcut is shown on your home screen

Sunday, May 30, 2021

Pac-Man Desk Clock Real Time Clock (RTC) Mod

The Pac-Man Desktop Clock!

Back in 2015, Raw Thrills made a pretty cool desktop clock featuring Pac-Man and the ghosts.  This LED pixel clock had animations was commonly found for about $40 on sale.

Clock in Action - https://www.youtube.com/watch?v=2MTn2QNU2-o

There were two main complaints with the clock.. 

  1. It was desktop style only, it's form factor did not lend to being directly mounted on a wall and 
  2. It lost it's time whenever powered off (and drifts pretty badly even when continuously powered)... so pretty much was guaranteed to always have the wrong time.

The good news is, the unit was originally designed to have a RTC (real-time clock) and battery, but these pieces were costed out before production.  According to Josh Sharpe at Raw Thrills, prototypes were also intended to have sound, but sound had to be removed when they couldn't get it working reliably on the production hardware.  When costing out the RTC, the PCB was not changed, they just removed the components making it easy for us to add the functionality back!

Adding the RTC back in as a mod was discussed on the Pinside.com forum (Thread Link) and members submitted their findings on adding the required components.  Member empty-m even linked the parts he used from digikey.com making it easy to ID what you needed (Post Link).  But ironically, most must have found it so simple that no one bothered to document the process completely.  Well, I figured that wouldn't do, so I'm making this post :)

Parts needed:

Here are the items as identified by empty-m - These have been verified to work.  Others can be substituted, but you're on your own there :)

  1. Timekeeping chip DS1307ZN+T&RCT-ND (Digikey Link)
  2. Crystal 535-9033-1-ND (Digikey Link)
  3. Battery holder BC501SM-ND (DigiKey Link)
  4. CR1220 Battery (DigiKey Link)

When I sourced this for my own kit, it cost me $5.86 +shipping.. so this is cheap :)

Tools needed:

  1. Small Phillips Screwdriver
  2. Plastic Spluger Recommended (Found in most phone repair kits) - Can use a simple credit card if you have nothing else
  3. Soldering Gun, solder, flux
  4. A pair of tweezers is recommended - used for for placing/holding SMD components
  5. Magnifying glass, loupe or equivalent recommended - used for looking at tiny SMD joints
  6. Flux-remover or Isopropyl alcohol - used for cleaning up solder flux

Experience needed:

Moderate - This job is actually really straight forward, but it does require you to solder very tiny SMD components.  If you have never soldered before, this maybe a tall order for you!  If you have SMD experience and tools - this is a piece of cake!  If you are comfortable doing through-hole PCB soldering, you can hack this simple SMD job 

Modification Step by Step Guide

1.  Unplug the clock and take to your bench or work area

2.  The front tinted plastic must be removed.  It is held in with dabs of hot glue in the four corners. 

To remove, start in the middle and pry your plastic spluger or credit card in the gap between the case and front screen.  Get behind the plastic and just work your way along the edge towards the corner.  The screen will easily bow and lift away from the case.  Just be gentle and avoid bending the plastic to where it would snap.  The hot glue easily gives way without heat or extra effort needed.



Here you can see the small amount of hot glue holding the panel in


Once free, set the plastic screen aside where it won't get scratched.

3.  Remove the 4 visible Phillips screws from the back of the unit and keep the screws where you won't lose them.

4.  Using your screwdriver or another thin stiff object, push the screen out of the case from the back by pushing through the screw holes in the back of the case.  

The screen is held in place only by friction and the hot glue that held the front-screen in place.  Just push gently through the holes, trying to evenly advance the screen forward until it comes free of the case.  Holding the case at an angle so its supported, but not blocked at the front is helpful to pushing the screen out.




Warning!  The screen is attached via wires to the PCB which is still attached to the case, so it will not come out completely.  Just separate the screen from the case enough you can access the PCB

5.  Move the screen away enough so you can access the four Phillips screws holding the PCB board in place.  Remove the four Phillips screws and set aside with the other screws you removed previously.  They are all the same type.

Once free, set the case aside and leave the screen face down on your work surface where you can easily access the component side of the PCB.


The three places of interest on the PCB are the spot labeled U3 which is 8 pads in a square shape, Y2 which is 2 pads side by side, and the battery BT1 with two pads.


Now the fun soldering part!

I am going to assume most people doing this are not SMD experts and don't have SMD specific tools.  I'm documenting this using normal through-hole tools.  I am not a SMD guru - there maybe other ways you may want to do these steps, I'm just giving you one way.  I used a Weller temperature controlled iron at 610F with a chisel tip, and paste flux.   I also use spray flux remover which allows me to clean up flux easier.

Some tips

  • Magnification is key!  Always use magnification to see what you are doing
  • Flux is sticky and helps hold parts in place.  Putting flux on the pads not only helps your solder flow, but helps keep your part from running away on you
  • If you feed solder directly to the joint, you don't necessarily need to put flux on the pad before soldering.  If you pre-load the solder to your tip, the flux will be burned away, so put flux on the joint when using solder that was pre-loaded on your iron's tip.

6.  Install the clock chip at U3

Prep the 8 pads at U3 by covering the pads with liquid flux or flux paste, this will help your solder flow, and helps keep the part in place.

Using tweezers, toothpick, or other small tool, place the 8 pin chip on the pads at U3.  The small dot on the chip denotes pin 1 which should be oriented next to the U3 label screen printed on the board.  Reposition as necessary to get the chip's legs aligned on the solder pads.  Use your magnification tools and get it lined up correctly.

Using my digital magnifier to check alignment - See how the chip's legs line up to the pad

Clean your soldering iron tip, then get a small blob of solder on the tip of the iron.  While holding the chip down in place with your tweezers, briefly touch the soldering iron to the intersection of the pad and the chip leg.  The solder should quickly wick from the iron and flow to the leg and pad.  If the solder didn't flow, try again holding slightly longer.  It should wick in under a second - if not, make sure your part is flat and you are making contact with the pad and leg.

In the photo above, you can see I used high-temp tape (the orange tape) to help hold the component in place so I wouldn't have to hold the part in place while trying to tack the first leg.

Once the first leg is soldered, and you are happy that the component hasn't moved and all the other legs are still aligned.  Solder the rest of the legs the same way.  Get a dab of solder on the iron, touch to leg and pad until solder wicks up to leg.

Soldered Pads before the flux has been cleaned up


Alternative soldering methods include holding the solder at the intersection and touching the iron to the joint, or "drag soldering" where you get a mass of solder on the tip and continuously drag the tip over the pad/leg intersection.  Youtube for your favorite SMD soldering advise :)

For such a small chip, I found both the pre-loaded tip and holding the solder across the joint effective.  Use your magnification tools to make sure the solder wicks up into the joint and that your legs are all well connected to the pads.

Once you are happy with the soldering.  You may want to clean up your flux before placing the other components.  Using flux remover or simple 90%+ isopropyl alcohol flush the area and wipe away any flux.  A small brush or q-tip helps.  Blow out any excess fluid and check your work with magnification before proceeding.

7.  Install the oscillator at Y2

The small oscillator crystal is a cylinder with two legs.  The part can be installed in either orientation, you just want to make sure it fits and doesn't get obstructed by other parts.  The legs are very short, so I opt'd to install it vertically, then laid it over the clock chip we just installed.

Prep the two pads at Y2 with solder.  Heat the pad and add solder to the pad to create a small mound.  Just enough to create a small pile - not a mountain.  Do this for both pads.

Holding the crystal in tweezers, position it so it stands upright with its two legs touching the pads.  Using your soldering iron, heat up the pad (which is loaded with solder) and let the leg of the crystal drop into the mound.  Quickly repeat with the second pad so that the legs of the crystal are both secured into the solder on the pads.  If secured, lean the crystal over towards the U3 chip and make sure the legs do not short anywhere.


View of the crystal installed and 'leaning' over U3 - Lots of flux yet to be cleaned!

Again, access to the area is tight, so you may want to clean up any flux before proceeding.  Use your flux remover or Isopropyl alcohol. 


8. Install the battery holder at BT1

Place the battery holder so its legs line up with the two pads for BT1.  It should be oriented so the open side of the clip is on the side furthest from U3.

With these large clips and pads (compared to what you did on U3!) you can solder these legs anyway you like.  I held the clip in place and held the solder on the joint and heated the joint with my iron.  Make sure your solder wicks between the leg and pad.


9.  Clean up any flux and inspect under magnification.  

Using your magnification, check for any remaining flux reside, clean if necessary so you don't have any paste or baked goo left around your parts.  Inspect the soldered joints and correct any by reheating if necessary or removing excess if you have any solder bridges.  Make sure all legs are connected and you have no shorts/bridges.

10.  Install the Battery in the battery holder

Simply slide the battery in from the open side and under the brass lip.  Get it under the lip, then the open end will snap into the holder when the battery is pushed down.

11.  Once you are confident the PCB is dry of any fluids used to clean it you can bench test your work.  

Just make sure the PCB isn't contacting anything to short, plug in the 12V transformer, and confirm the unit powers up.

Once powered, use the buttons to set a time on the clock besides the default 12:00.  Just set it to 12:05 or something.  Then unplug the clock from the wall.  Wait 2 minutes, then plug the clock back in... it should be showing 12:07.  If it is (or later..) your did it!  It works!  If it shows 12:00, the RTC feature did not work and you should re-check your soldering.

12.  Remount the PCB to the case using four of the screws.  

Reinstall in the same orientation you found it.  The power connector on the PCB should make sure you have the correct orientation of the board.  The component side is towards the back of the case, and the two power wires feed around the PCB at the bottom edge.

13.  Feed the screen back into the case.  

Again, it is just friction mounted, no fasteners.  Just feed in evenly.  The hot glue from the original install helps create some friction.

14.  Reinstall the front plastic by simply pressing into place.  

The original hot glue should still be there and be sufficient to hold the panel in place.  If not, add a dot of fresh hold glue in the corners to secure it.


That's it!   Enjoy a clock that keeps the real-time!

Wednesday, December 11, 2019

What is ROE? For Star Trek Fleet Command iOS and Android


What is ROE?

ROE stands for “rules of engagement”.  It’s a concept borrowed from military lingo by players of Star Trek Fleet Command on iOS and Android to describe a set of player vs player rules that regular players have adopted as a community convention for playing the game.

Much of the online content you find in Google searches about ROE is from the PC version of the game which is similar, but not exact to the mobile game.  This article is specific to the mobile OS version of Star Trek Fleet Command

Rules?  Says who?

In these play-to-advance free-mium games it can be hard to keep progressing in the game without spending tons of money.  To combat that trend and to advance the interest of ALL players, ROE was established by players, for players, so that we can all get through the grind aspects in the game while not completely nerf’ing player vs player action in the game.  ROE allows us to function for day to day activities the game requires, while still keeping the PVP aspect of the game intact.

ROE is not a rule as defined by Scopely (the games developer).  As such, it has no formal representation in the game itself.  Instead, it is convention agreed upon by the most active alliances on your server.  The rules are established by a vote of admirals from those alliances and published in a common place.  Players self police themselves with the consequences of retaliation and alliance backing when players violate the ROE.  Disputes are handled between admirals of the involved alliances.

Why should I follow ROE?  It’s not part of the game!

ROE is a convention for players, by players.  It is to your advantage in the long run to benefit from the protection ROE gives you.

Often new lower level players think they don’t need ROE and "it's dumb", it just limits them etc.  That is because those players below level 18 or so have not seen how demanding the game becomes and do not understand what is ahead of them.

It is true that some alliances and groups of players do not acknowledge or follow ROE.  Those alliances generally advertise that on their alliance info block (click on the Magnifying Glass in a Player's Detail page).  Those alliances do not get the protection of ROE from other players.  Some alliances are so powerful they chose to reject ROE and do so by pure strength. 

Well what are the Rules of Engagement/ROE?

The accepted definition of ROE may vary server to server.  Star Trek Fleet Command has dozens of separate instances/servers that a player is assigned to when their account is created.  Ask in Galaxy chat of your game for a pointer to where your servers definition is posted.

For server 32 the Agreed upon ROE is as follows: (as of Dec 2019)

————————————————-
Survey Ship Hits
- If a survey ship is on a zeroed node, send a warning message before attacking.
- If a survey ship is over the protected cargo, it is free to hit.
- If a Survey ship is under protected cargo and is not on a zeroed node, it is protected by RoE and can not be hit.  (Exception if a survey ship is involved in base raid, base defense, or has otherwise engaged in PvP combat (other than an attack within ROE that clears a mining node) then they are fair targets.)

Warship Hits
- Warships are not protected by RoE.

Station Hits
- Stations are not protected by RoE.

KOS
- If an alliance or player is labeled KOS by your alliance, they are not protected by RoE.
- Only Admirals can call KOS.

Retaliation
- If you are attacked outside of RoE, you may retaliate outside of RoE once within the same 24 hours you were attacked.

Swarm/System Event Space
- Any ship over protected cargo is free to hit after a warning.
- Any ship under protected cargo is protected by RoE.
————————————————-

What is zero node, protected cargo, OPC, etc?


  • Nodes are the resource spots in the game where your ships gather resources such as trilitium, parasteel, etc.  ROE applies to all resource node types.
  • Zero node is a node that has been depleted to zero and stays at zero until the current ship leaves the node or is destroyed.
Zero Node Example
Selecting the node shows 0 resources available - This is a zero node

  • Protected cargo is the amount of cargo your ship protects and you do not lose when your ship is destroyed.  The amount of space is shown by the split in the bar that fills up in your ship’s status panel.  It can also be seen in the details tab about the ship.  The amount will vary by your ship’s class, level, and the crew assigned to it.
Split in Ship Details
Portion to left of split is your protected cargo space

Protected Cargo Details
As seen from the Manage Ship page - Under Details tab
  • OPC - “over protected cargo”.  A ship that is carrying more cargo than its protected cargo limit is referred to as OPC.  You can tell if a player's ship is OPC by checking the possible rewards for defeating a ship. If any resource types are shown (not including chests!) then you know the ship is OPC.
Over Protected Cargo Example
This ship shows Decoded Data Resource as a reward - so this ship is OPC

  • UPC - “under protected cargo”. A ship that is carrying LESS cargo than its protected cargo limit is referred to as UPC. You can tell a ship is UPC by checking the possible rewards for defeating a ship. If no resource types are shown (not including chests!) then you know the ship is UPC.  
Under Protected Cargo Example
This ship shows no resources in the Rewards panel, so this ship is UPC

  • KOS - Kill on Sight. When a player is declared KOS by an admiral, it means all players from that admiral's alliance are free to ignore ROE constraints and attack the named player in any circumstance.  Being named KOS is normally retaliation for repeated problems with a player
  • Reset - Refers to a player leaving a node that is zero'd so it resets the resources amounts available and quickly returning to the same node.  When a player is in process of resetting a node, courtesy is to allow the player to complete the task without interference.
  • Warships - All ship types that are NOT surveyor class ships (ships with the inverted triangle icon) are considered warships and are not protected by ROE except in special cases (refer to ROE above)
  • Swarm Space - Systems on the map that exclusively have the Swarm Hostile ship types.  Swarm space normally has special exceptions for ROE protections.  See ROE list above.
  • Event Space - Systems on the map that are tied to a special (usually timed) event from the game developer.   The event usually names key systems where activities must be performed.  Event space normally has special exceptions for ROE protections.  See ROE list above.

What do i do if someone doesn’t follow the ROE?

First, communication is key!  Don't try to make every kill into WWIII or complain endlessly.  Pick when to make an issue of things.  Your reputation in the game is not trivial.

  1. Check your log and see if you were OPC.  If you show any resources lost in the fight, you were OPC and the hit was allowable in most normal circumstances.  Refer to the ROE list above.
  2. Check your inbox for any messages that you were on a zero node.  Players should message you prior to hitting you if you were on a zero node.  This helps avoid confusion over why you got hit.  Courtesy is to wait a few minutes after sending the message before hitting someone on a zero node.  This also helps establish time between timestamps when addressing disputes.
  3. If you believe the kill was not ROE-compliant, take a screenshot of your log details for the battle.
  4. View the player's profile and check their alliance details.  See if they advertise following ROE or not.  If not - accept that and react as you and your alliance see fit.  If they do follow ROE...
  5. Message the player and challenge then why you think it was out of ROE.  If you act like a jerk, don't be surprised if you get attitude back.  Listen to the player - sometimes simple timing issues lead to mistake kills, or fat-fingered something.  'Do unto others...' and message them proactively if you hit someone mistakenly as well.  Try to clarify if the hit was intentional or within the rules.  Note that many newer or lower level players (under Level 18) are not familiar with ROE.  Point them to their alliance for support if they are unclear, or help them by pointing them to resources to help them understand.  If there is a dispute, take screenshots of your chat for future discussions.
  6. If you still believe the hit was not within ROE - server32 ROE allows you to retaliate once within 24hrs and hit one of the player's ships ignoring ROE protections.
  7. If the situation escalates, or you have repeated problems with a player, look at their player profile, view their alliance details and message their admiral explaining your dispute with the specific player.  If you can not get a reasonable response, escalate the issue to your own admiral.
  8. Platforms like Discord are very helpful to share supporting information (screenshots) between players.  Inquire if your alliance and/or server have a Discord instance where files are easily exchanged.  Use screenshots to capture details about your exchange in a dispute.  Your battle log to show who attacked who, timing, your chat log, etc.

How do I avoid being called out for not playing within ROE?

  1. First, follow the rules for your server's ROE
  2. When attacking OPC ships, nothing extra is needed as your battle log (for both parties) will clearly show where the attack was and if a ship was OPC
  3. If a ship is on a zero node, make sure you send a message to the player BEFORE you attack.  Be courteous and give the player a few minutes before attacking.  (I normally give 1-2mins.. usually my transit time, plus the time as I'm looking at other nodes in the area)
  4. It can be helpful to take a screenshot showing the node as zero before your attack, just in case someone disputes it later
  5. Avoid risky behavior that can lead to mistakes
    1. Don't set to mine a target when your ship is outside the system.  Instead set the ship to warp near the node, and then switch to the node once the ship arrives
    2. Do not set to attack targets from 'long distance'.  A lot can happen in 30-45 seconds.  Move near the target where you can see it and watch your ship come in before you set it to attack the target


Monday, October 10, 2016

AD LDS for Cisco CMS - Local users and userProxy setup

Purpose
Need an LDAP server, but can’t use your Active Directory for various reasons, and you don’t want to install a linux OpenLDAP setup?  If you have a Microsoft Windows Server available, you can install the Active Directory Lightweight Services (AD LDS) feature as a simple stand-alone LDAP server or as a proxy to your Active Directory you can augment with your own needs.  Using AD LDS you can create your own users and groups using local passwords you control, or you can also add proxied users where you use the passwords from your enterprise directory.  This guide will go through two setups: 1) setting up the minimum needed to have a stand-alone LDAP you will not sync with Active Directory and 2) Expand upon that basic setup to add importing and proxying of users from Active Directory.

This guide is written assuming Windows 2012, but should apply equally to Windows 2008.  

Chapter 1: Stand-Alone LDAP using AD LDS
Pre-requisites
A Windows Server 2012 server you have administrative rights to (Note covered, but should apply to Windows 2008/R2 servers as well)

Disclaimer 
While CMS has been tested by Cisco Sales to interoperate with Active Directory Lightweight Services (AD LDS), Cisco TAC can not provide support/guidance on operating your AD LDS instance.  It is recommended you work with your internal Microsoft resources or partner if you need assistance with maintaining or troubleshooting your AD LDS instance.  This configuration requires significant interaction with Active Directory as a LDAP server.  This document serves as a guide of a example configuration that has been validated to work, but is not intended to be all encompassing documentation for Microsoft’s AD LDS.  This configuration was documented and tested with Windows Server 2012 and CMS v2.0.4

Install AD LDS Service

Use the Server Manager, from the Manage Menu, select to add a New Role.  Use the Wizard to Add the Active Directory Lightweight Directory Services role to the local server - you can just click through the Role Wizard with the defaults.  Once the wizard completes, it will provide a clickable link to launch the configuration wizard for the service.  Click and start the configuration wizard

Proceed through the configuration wizard using the following guidance
  • when prompted for what type of instance to use, select A unique instance
  • when prompted for a name for the instance, use a label of your choice.  Note this label is what the service will be identified as when looking at the Windows Services Control Panel
  • leave the default port numbers of 389 and 636
  • when prompted for specifying if you want to create an application directory partition, select Yes, create an application partition, and specify the ldap root DN you want for this directory.  Example:  dc=cms,dc=lab
  • when prompted for installation path, leave the default or set to a path of your choice
  • when prompted for what service user to use, leave the default which is to use the Network Service account
  • when prompted for for assigning administrators to the service, leave the default choice of adding the current logged in user
  • when prompted for which LDFs to import, mark the checkboxes for import for MS-AdamSyncMetaData, MS-InetOrgPerson.ldf, MS-User.ldf, MS-UserProxy.ldf, MS-UserProxyFull.ldf
  • Complete the rest of wizard and finish

Add a service user for CMS
You will create a user in the AD LDS directory to use as the service user to allow CMS to connect to the directory.  This account only needs reader access to the directory for CMS to function.

  • From the Windows Start menu, type ‘ADSI Edit’ and open the utility from the search results.  Once opened, right click on the item in console tree, select to Connect to.  Set the Computer value to localhost:389  .  Select the option for Connection Point to Distinguished Name and enter the ldap DN you set in the installer.  Ex:  dc=cms,dc=lab  and click Ok

  • Once connected, expand the tree on the left.  Right-click on the root level folder (dc=cms,dc=lab) and select New->Object..  Select type user, click Next.  Set the Common Name you want for the new service user account (Example: cmsuser).   Click Next and Finish
  • Right click on the entry created for the user and select Reset Password.  Enter a password for the user and click Ok to save
  • Right click on the entry for the user and select Properties.  Scroll in the list until you find msDS-UserAccountDisable.  Double-click and set the value to False.  Click ok. 


  • Double click the entry for msDS-DontExpirePassword and set to True then click Ok. Click Ok again to close the Properties window for the user 
  • Expand the folder tree and click-on the folder CN=Roles.  In the list, right-click on CN=Readers and select Properties
  • Find the property named member in the list and double-click

  • Click the Add DN button and add the full DN of the user you created in the previous steps for the service user.  Example: cn=cmsuser,dc=cms,dc=lab  .  Click Ok, and Ok again to close the properties windows.

You now have an ‘empty’ LDAP server you can connect to via LDAP bind

Test the service user
You will use the built-in Windows ldp.exe LDAP utility to test connecting to the server using the newly created service account
  • From the Windows Start menu, type ‘ldp’ and open the utility from the search results.  Once opened, under the Connection Menu, select Connect.  In the server field, enter localhost and set port to 389.  The two checkboxes should be unchecked.  Click Ok.  A large amount of text will go by in the console, but it should not report errors
  • Under the Connection Menu, select Bind
  • Set Bind type to Simple bind
  • For username, put the full LDAP DN of the user you created
    • Ex: cn=cmsuser,dc=cms,dc=lab  
  • Enter the password you set on the account and click Ok to connect
  • If successful, the console will say ‘Authenticated as: ‘CN=…’ 
  • From the View menu, you can select Tree and in the drop down, select your top level DN (Ex: dc=cms,dc=lab) and click Ok.  The directory structure is then browsable in the client
This confirms your LDAP user details for use by CMS.  This test was from localhost, before attempting to connect from a CMS server, ensure LDAP 389 is allowed through the local Windows Firewall on the server if it is use

Enable SSL for LDAP server
The LDS Instance can use LDAP over SSL but must have access to a Certificate and Private key to function.  Without SSL, the LDAP user passwords will be in the clear on the network, so configuring SSL is recommended.

The LDS service can use a certificate from the service account’s Certificate Store, or the Computer’s Certificate Store.  This guide will outline using the Computer account as the Certificate Tools are limited when using the Service User accounts.  The default service user for AD LDS (Network Service) will not have permissions to a private key loaded in this certificate store by default so permissions must be granted.

  • Securing a certificate through a CSR, or enrollment from an Enterprise CA will not be covered in this guide but follows standard Window’s certificate tasks.  Import a certificate to the Computer’s Certificate Store using the Certificates Snap-In for Microsoft Management Console (mmc). 
  • Once a certificate is loaded in the Personal Store, right click the certificate, select All Tasks and Manage Private Keys.  If Network Service is not listed in the user list, click the ‘Add’ button, search for Network Service and add it to the list of users.  It will default to have Read and Full Control permissions.  Click Ok to save the changes and the Certificates Snap-in can be closed.  Restart the LDS windows service, or just restart the server
  • SSL can be verified using the ldp.exe tool to connect to the server as was previously, but when specifying the server values in the Connect screen, you must enter the hostname that matches the name on the certificate, set port to 636 and mark the SSL checkbox.  If you connect without errors, SSL is functioning properly. 
  • - If not, check
    • your firewall configuration for TCP port 636
    • your certificate's attributes for CN or SAN names and that it matches the hostname used in the ldp client
    • that the certificate is stored in the computer account
    • that the service user running LDS has read permissions to the private key
Extend the default schema
The default AD LDS schema is very lightweight and does not include common attributes you may see when trying to mimmic an Active Directory example.  Extending it to the Windows2008 functional level will open more opportunities and should be done to avoid later issues with incomplete schemas.

  • Open a command prompt on the server hosting LDS, and change to the adam directory under your Windows directory.  Ex:  c:\windows\adam
  • Issue the following command to import the Windows 2008 Forest Schema
ldifde -i -u -f ms-adamschemaw2k8.ldf -s localhost:389 -c "cn=Configuration,dc=X" #configurationNamingContext
  • The command should show progress and then report Command completed successfully

Adding a user to the LDAP for a CMA user
The LDS directory functions just as any other LDAP or Active Directory where you can create users, groups, and place them in containers or OUs of your choice to organize them.  These items can be created using virtually any LDAP tool or ldif imports.  Since this guide is covering a bare essentials setup, we will outline how to create a user using Microsoft’s ADSI Editor.  To be an account that can be authenticated locally by the LDS instance, you will need to create a user object, set a password, and have the msDS-UserAccountDisabled attribute set to False.  You should configure any attribute you will use with your CMS LDAP mappings.

NOTE:  sAMAccountName is a common attribute used by CMS LDAP mappings (and used in most documentation examples).  This attribute is not present in the default schema, but was added when the schema was extended to the Windows2008 functional level.  However, this attribute is not editable using the ADSI Editor GUI utility.  If you are only using a stand-alone LDAP and wish to use the ADSI GUI tool, you may wish to substitute another attribute to use in sAMAccountName ’s place, such as employeeID which can be edited in ADSI Editor.  Alternatively, you can create ldif files and make adds/changes using those files.

Using ASDI Edit to add a locally authenticated user
  • From the start menu, type ‘ADSI Edit’ and open utility from the search results.  Once opened, right click on the item in console tree, select to ‘Connect to’.  
    • Set the Computer value to localhost:389
    • Select the option for Connection Point to Distinguished Name and enter the ldap DN you set in the installer.  Ex:  dc=cms,dc=lab  and click Ok
  • Optional - You can create an OU to organize your users.  Right-click on the folder level to add the folder, select New -> Object, select organizationalUnit and give it a name.  Best practice is to organize users into OUs for easier filtering/searching
  • Expand the tree on the left.  Right-click on the OU or folder where you want to create the user and select New->Object..  Select type user, click Next.  Set the common name for the user Ex: 'John Doe’ and click Next and then click Finish
  • Right click on the new entry for the user and select Reset Password.  Enter a password for the user and click Ok to save
  • Right click on the user and select Properties. In the Attribute Editor, you will set the values for this user.  At the minimum you must add all the attributes you plan on using in your ldapMapping properties with CMS.  Because for this example this is a stand-alone LDAP that is not replicated from an enterprise directory, you can use whatever values you desire as long as the users have unique DNs, userPrincipalName attributes, and your resulting ldapMappings will result in unique usernames and space URIs.  Recommendation for the minimum fields include
     displayName
     employeeID*
     mail
     telephoneNumber
     msDS-UserDontExpirePassword = true
     msDS-UserAccountDisabled = false
     userPrincipalName    (if using CAC cards)

For each attribute to set, double-click the attribute from the list, set the value desired, and click Ok.  Click Ok when done editing the user.


*NOTE - sAMAccount is a common attribute in CMS documentation, but is not editable in ADSI Edit.  If you prefer to use ADSI edit, you may want to substitute using another attribute such as employeeID and not use sAMAccountName.  This example is shown using employeeID

TIP: The Filter button in the ADSI Editor attribute page may be filtering out options you are looking for.  Click the button and ensure the Show only attributes that have values is unchecked to see all possible attributes.

Using ASDI Edit to add a user group
  • From the start menu, type ‘ADSI Edit’ and open utility from the search results.  Once opened, right click on the item in console tree, select to Connect to.  
    • Set the Computer value to localhost:389
    • Select the option for Connection Point to Distinguished Name and enter the ldap DN you set in the installer.  Ex:  dc=cms,dc=lab  and click Ok
  • Expand the tree on the left.  Right-click on the OU or folder where you want to create the group and select New->Object..  Select type group, click Next.  Set the common name for the user Ex: ‘Video Admins’ and click Next and then click Finish
  • Right click on the user and select Properties. In the Attribute Editor, find the member attribute and double-click.  The member attribute is a list of all users who are a member of this group
    • Click the Add DN button and enter the LDAP DN of the user you wish to add to the group (Ex:  cn=Jane Doe,dc=cms,dc=lab).  Click Ok, and repeat the process to add additional accounts.  Click Ok when complete.

TIP: Groups can have both users and other groups as members.  You can reference groups in your CMS LDAP filter as a way to select which users to import.  The following LDAP filter recursively selects members of the group cn=video admins,dc=cms,dc=lab  :  Example  memberOf:1.2.840.113556.1.4.1941:=cn=video admins,dc=cms,dc=lab

Adding a locally authenticated user using ldif
ldif files are simple text files fed into a ldif utility that will make the instructed changes to objects in the LDAP directory.  The text files must be customized to the change intended and syntax is critical.  Unfortunately the error messages from the server and ldif utilities are usually very cryptic and difficult to interpret.  AD LDS uses standard LDIF files and syntaxes.  Examples are given here to assist. 

To process a ldfi file against your LDS instance.
  • While logged in to the server hosting LDS as the user you added as an administrator when installing LDS, Open a command prompt
  • For simple ldif files that include full DN references (example:  enlisted.ldf.txt) , use the following command:   ldifde -i -f enlisted.ldf.txt -s localhost:389
  • A successful import will look like this

A failed command may report syntax errors or schema violations for the changes submitted

The following examples provide starting templates for common tasks.  To use, copy the example text to a text file in a program like Notepad.exe  Edit the dn field to the DN of the object you are trying to manipulate, and edit the attributes and values to match your intended change.  These examples are given as starting points.  You may use general LDAP and ldif command references for additional help.

To add a locally authenticated user via ldif
The file must include the DN to where you want the user to be located, and edit the attribute list to match the intended values.  Take special note of the password handling steps provided after the example.  The account can not have the msDS-UserAccountDisable attribute set until after the user has a valid password.  

Example user add.  Adds ‘Bob Smith’ to the existing ‘Local users’ folder
-------- CUT HERE ----------
dn: cn=Bob Smith,ou=Local Users,dc=cms,dc=lab
changetype: add
objectClass: user
displayName: Bob Smith
givenName: Bob
sn: Smith
mail: bob.smith@company.com
telephoneNumber: 7035551211
employeeID: bob.smith
sAMAccountName: bob.smith

-------- CUT HERE ----------

NOTE: Passwords can not be set via plain-text or non-SSL connections.  Setting the password is possible using base64 encoding - See https://support.microsoft.com/en-us/kb/263991 but can easily be done after the user is already in the directory using the ADSI Editor and selecting Reset Password.  So to complete the task of adding a new user, import the user via ldif, then set their password and the msDS-userAccountDisable attribute using following steps in ADSI Edit:
  • Right click on the entry created for the user and select Reset Password.  Enter a password for the user and click Ok to save
  • Right click on the entry for the user and select Properties.  Scroll in the list until you find msDS-UserAccountDisable.  Double-click and set the value to False.  Click ok. 
  • Double click the entry for msDS-DontExpirePassword and set to True then click Ok.  Click Ok again to close the Properties window.
Modify an existing user’s attribute via ldif
To add a new attribute or complete replace an existing value.  This example adds or replaces the sAMAccountName value for user cn=Bob Smith,ou=Local Users,dc=cms, dc=lab
Example user modify
-------- CUT HERE ----------
dn: cn=Bob Smith,ou=Local Users,dc=cms,dc=lab
changetype: modify
replace: sAMAccountName
sAMAccountName: bobby.smith
-
-------- CUT HERE ----------


Configure CMS for the LDS LDAP server
There are no special considerations needed to make the CMS LDAP import work with the AD LDS instance.  The server connection settings are done the same as when connecting to Active Directory, but it is recommended you use port 636 and secure connection option as LDAP bind alone does not protect passwords being transmitted over the wire.  Make sure any attributes you use for your LDAP filter and LDAP mappings are attributes that are defined in your LDS objects.  (Ex: do not try to filter on a attribute that is not populated in your LDS users).

Configure your server connection settings with the service user you created in earlier steps.  NOTE: unlike ActiveDirectory, authenticated users do not have read access to the LDS directory by default.  Only users added to the Reader or Administrator roles in LDS will be suitable for the service user for CMS LDAP settings.  This guide instructed you to create a local LDS user object to use as the service user, and that should be the user configured in CMS

Complete the LDAP base DN, filter, and mapping settings as you normally would.  Remember you can only use attributes you have populated in the LDS server.  

TIP: Make sure all users included in your ldap filter have all the attributes necessary for your ldap mappings.  The service user created may not have these and may cause ldap sync to fail.  If that is the case, exclude the user from the import using your LDAP filter, or add the necessary attributes to the user using ADSI Edit or ldif import.


Chapter 2: Configure LDS with proxied authentication
The prior chapter outlined configuring LDS to operate as a stand-alone LDAP server where you would create users and groups that can be used with your CMS installation.  The negative to this setup is you need to manage the passwords in this LDAP and create all the users and groups yourself.  What if you wanted to use the users and groups from Active Directory, but just needed the ability to add some of your own extra stuff, but can not do it in Active Directory itself?  

LDS can be configured to import your Active Directory into your LDS instance, and allow users to connect to your directory, but still be authenticated by the true Active Directory.  This is achieved with ‘userProxy’ objects in LDS.  A version of the user’s LDAP attributes are copied into your directory as a ‘userProxy’ object, which includes a link back to the original user record in ActiveDirectory.  When a user tries to bind to your LDS, the authentication portion is proxied back to Active Directory, while the rest of the contents come from your LDS instance.  This allows you create shadow copies of your Active Directory entries and mix them with entries of your own.  Have user accounts in AD, but not the security groups you desire?  Using LDS, you can import the enterprise users into LDS, create your own security group in LDS, and have CMS use the LDS security group to filter users by.. but when users authenticate, its done by the enterprise Active Directory!  This gives you the best of both worlds, but is a directory that the administrator would have to maintain.

Disclaimer:  While CMS has been tested by Cisco Sales to interoperate with Active Directory Lightweight Services (AD LDS), Cisco TAC can not provide support/guidance on operating your AD LDS instance.  It is recommended you work with your internal Microsoft resources or partner if you need assistance with maintaining or troubleshooting your AD LDS instance.  This configuration requires significant interaction with Active Directory as a LDAP server.  This document serves as a guide of a example configuration that has been validated to work, but is not intended to be all encompassing documentation for Microsoft’s AD LDS.  This configuration was documented and tested with Windows Server 2012 and CMS v2.0.4

Functional explanation
In the previous chapter, we setup LDS with ‘user’ objects with passwords.  These objects are defined in LDS and allow a client to do a simple LDAP bind using the password stored in the ‘user’ object’s attributes.  Now, we will use a utility named adamSync to read user objects from your enterprise Active Directory and create a matching object in LDS, with a subset of the attributes from the user’s definition in Active Directory.  But instead of creating ‘user’ objects as we did before for users, adamSync will create ‘userProxy’ objects.  This ‘userProxy’ object differs from ‘user’ objects by having an AuxillaryClass associated with it, that when seen, LDS knows if someone tries to bind with that object’s DN, to authenticate the user not with a local password, but by passing the password to the underlying Windows subsystems.  When adamSync creates the ‘userProxy’ object, it includes the Security ID (SID) of the user it copied from in Active Directory and that, along with the password supplied in the login/bind request, is what is tested by Windows to grant the request or not.

CMS can sync it’s local users with any type of object in the directory, so it can create users from both ‘user’ and ‘userProxy’ objects in the LDS directory.  The difference is simply when CMS tries to bind to LDAP to test a user’s login, users imported from ‘user’ objects in LDS will have their password checked locally by LDS, users linked to ‘userProxy’ objects will have the password verified by Active Directory.  The ‘user’ and ‘userProxy’ objects should include the attributes that you are interested in using in your LDAP Mappings (mail, telephoneNumber, etc).  Additional objects such as groups can also be synchronized into your LDS so they can be used by the filter settings when configuring your CMS ldap settings for filters, containers, etc.

Pre-requisites for proxied authentication
  • A Windows Server 2012 server you have administrative rights to (Note covered, but should apply to Windows 2008/R2 servers as well)
  • The Windows Server must be a member of the AD domain to authenticate users.  Other domains can be included as well if there is a trust between the computer’s domain and the other domains
  • You must have an existing Active Directory you will be importing users from

Install LDS Service
The installation of the AD LDS service and initial configuration is the same as the prior chapter.  You can add onto an existing LDS configuration setup as covered in the prior section, or if starting from scratch, complete the following sections from the prior chapter:
  1. Install AD LDS Service
  2. Add a service user for CMS
  3. Test service user
  4. Enable SSL for LDAP server
  5. Extend the default schema
Note, while using SSL was recommended in the previous section, it is required when using proxied authentication and the userProxy objects.  This can be disabled in the AD LDS configuration, but is not recommended since you will be sending Active Directory credentials in the clear if you do so.

Define Sync settings
  • Open Notepad.exe on the server hosting the LDS instance, and copy the following text to a new file.  Save the file in the adam folder in your windows directory and name it domainSync.xml
-------- CUT HERE ----------
<?xml version="1.0"?>
<doc>   
 <configuration>       
  <description>Cisco CMS Directory Sync</description>       
  <security-mode>object</security-mode>           
  <source-ad-name>pdc.company.com</source-ad-name>       
  <source-ad-partition>dc=company,dc=com</source-ad-partition>
  <source-ad-account>administrator</source-ad-account>               
  <account-domain>company.com</account-domain>
  <target-dn>dc=cms,dc=lab</target-dn>       
  <query>           
   <base-dn>dc=company,dc=com</base-dn>
    <object-filter>(&#124;(&amp;(sAMAccountType=805306368)(!(cn=Administrator))(!(cn=guest))(!(cn=krbtgt))(sAMAccountName=*))(objectClass=group)(objectCategory=OrganizationUnit))</object-filter>
  <attributes>
       <include>displayName</include>
      <include>givenName</include>
      <include>mail</include>
      <include>mobile</include>
      <include>sAMAccountName</include>
      <include>sn</include>
      <include>telephoneNumber</include>
      <include>userPrincipalName</include>
      <include>objectSid</include>               
      <include>member</include>   <!-- Do not add this attribute to userProxy object -->
    <exclude></exclude>
    </attributes>       
  </query>   
  <user-proxy>
      <source-object-class>user</source-object-class>
      <target-object-class>userProxy</target-object-class>
  </user-proxy>   
  <schedule>           
   <aging>               
    <frequency>0</frequency>               
    <num-objects>0</num-objects>           
   </aging>           
   <schtasks-cmd></schtasks-cmd>       
  </schedule>   
 </configuration>   
 <synchronizer-state>       
  <dirsync-cookie></dirsync-cookie>       
  <status></status>       
  <authoritative-adam-instance></authoritative-adam-instance>       
  <configuration-file-guid></configuration-file-guid>       
  <last-sync-attempt-time></last-sync-attempt-time>       
  <last-sync-success-time></last-sync-success-time>       
  <last-sync-error-time></last-sync-error-time>       
  <last-sync-error-string></last-sync-error-string>       
  <consecutive-sync-failures></consecutive-sync-failures>       
  <user-credentials></user-credentials>       
  <runs-since-last-object-update></runs-since-last-object-update>       
  <runs-since-last-full-sync></runs-since-last-full-sync>   
 </synchronizer-state>


</doc>
-------- CUT HERE ----------

  • Edit the file you just created and configure the following properties to match your environment
    • <source-ad-name>pdc.company.com</source-ad-name>  - Should be the FQDN of the Domain controller you wish to import from (the source)
    • <source-ad-partition>dc=company,dc=com</source-ad-partition> - The DN of the Active Directory Domain you are importing from
    • <source-ad-account>administrator</source-ad-account> - The AD Username of the user to connect to the source Active Directory.  This user must have read access to all the containers you intend to read from
    • <account-domain>company.com</account-domain> - Must be the Fully qualified DNS name of the Active Directory Domain you are importing from 
    • <target-dn>dc=cms,dc=lab</target-dn> - Set to the DN you configured for the LDS application partition during setup
    • <base-dn>dc=company,dc=com</base-dn> - Set to the top level of the Domain you wish to import from.  Recommend to set to the top level of the domain so you can handle any user moves.  Alternatively, you can set to a specific container if you have a very focused import
    • <object-filter>(&#124;(&amp;(sAMAccountType=805306368)(!(cn=Administrator))(!(cn=guest))(!(cn=krbtgt))(sAMAccountName=*))(objectClass=group)(objectCategory=OrganizationUnit))</object-filter>   - Controls which LDAP objects in and below the target-dn that will be synchronized.  This value will import users, OUs, and groups which should be sufficent for most needs.  If you wish to customize this LDAP filter, note the | and & characters should be encoded as follows: 
      • | (logical OR) substitute as &#124;
      • &(logical AND) substitute as &amp;
    • List of Attributes - these are all the attributes that the sync will read and sync over to your LDS directory.  This will limit what LDAP attributes from your AD that are available for your LDAP mappings in CMS.  If you need additional attributes from the user records, you can add them here following the existing syntax, but any user attributes you add *must* also add the attribute to the userProxy class using the AD Schema Editor (next steps).  Errors here will break the sync entirely
  • Save your changes, but keep the file open for reference. 
userProxy Schema
The default LDS userProxy object does not contain the common attributes that would normally be significant for a CMS installation, so we will use the Schema Editor to expand the list of valid attributes a userProxy can have.

Register the Schema snap-in
You only have to do this one time, it is not necessary each time you use the snap-in.

  • Log into the Windows server where LDS is installed with the user who has administrative rights to LDS
  • Open a command prompt and enter the command  regsvr32 schmmgmt.dll    You should get a pop-up saying DLL was registered successfully
Extend userProxy schema

  • From the Windows Start menu, enter ‘mmc' to search for the Microsoft Management Console and click to open
  • From the File Menu, select Add/Remove Snap-in and double-click the Active Directory Schema item to add it to the list of selected snap-ins.  Then click Ok
  • Active Directory Schema should appear in the Tree under Console Root.  Right-click on it and select Change Active Directory Domain Controller..  
  • In the dialog that opens, click in the table where it says to Type a directory name..  enter  localhost:389   and then select that row and click Ok.  You will get a long message about changing the domain you are managing and click Yes to acknowledge.
  • Expand the resulting tree structure, under Classes, scroll till you locate the userProxy object.  Right-click on it and select Properties
  • Select the attributes tab
  • In the optional box, you will see a single attribute userPrincipalName shown.  You must now add each of the attributes listed that were listed in the sync file created in the previous step.  Add an attribute by clicking the Add button, finding the name in the list, and clicking Ok.  Repeat this step until all the attributes in the sync file (except ‘member’ - this is not a user attribute so it should not be added to userProxy) are displaying in the Optional box.  Click Ok when completed.  You can close the Schema Editor/MMC window.  When prompted if you wish to save your console settings, you can select No.
ADAMsync
ADAMsync is a command line program that executes the actual sync that is scoped by the domainsync.xml file created in the previous steps.  The configuration xml file is loaded into the LDS directory, and the sync is triggered by executing the ADAMsync program with the /sync or /fs parameters.

This guide will outline how to execute this manually, but you can extend this functionality by having adamsync ran automatically using Windows Task Manager.  Any future changes (except passwords) will not replicate to your LDS directory from the enterprise AD until ADAMsync is re-ran.  Depending on the size of your directory and scope, this task may cause load on a domain controller.  Please consult with your Directory Administrators regarding automating your syncs.

Load the Sync XML file

  • Your command prompt should still be open in the adam directory below the Windows directory.  If not, open a new command prompt and switch to that directory
  • Enter the following command    adamsync.exe /install localhost:389 domainsync.xml   System should respond with ‘Done’.  If you are using an account for source-ad-account other than the user who will be logged in when performing the sync, add /passPrompt to the command when issuing the adamsync.exec /install command
  • Anytime you make any changes to the domainsync.xml file, the above command must be repeated to reload the configuration into the service.
Triggering the ADAMSync
The sync must be triggered using the command below.  Change dc=cms,dc=lab to the DN of your LDS partition (same value you set in the target-dn value in the sync xml file and set during install)
adamsync.exe /sync localhost:389 “dc=cms,dc=lab” /log out.txt

Open the out.txt file and check for errors.  The log will generate a lot of information, but jump directly to the bottom for the critical results.  You should not see any errors and you should see a line containing Updating the configuration file DirSync cookie with a new value.  near the end of the file which confirms the run was completed without error.  If there are errors, confirm the contents of the sync xml file and confirm all attributes listed in the sync file have been successfully added to the userProxy object.

Confirm Sync Success

  • From the start menu, type ‘ADSI Edit’ and open utility from the search results.  Once opened, right click on the item in console tree, select to Connect to.  
    • Set the Computer value to localhost:389
    • Select the option for Connection Point to Distinguished Name and enter the ldap DN you set in the installer.  Ex:  dc=cms,dc=lab  and click Ok
  • Expand the tree and confirm the containers from your Active Directory are now seen in your LDS instance.  Confirm that you see items for your AD users, but the type column should show ‘userProxy’ instead of ‘user’.

TIP: If your LDS gets to a state you are uncertain of, running the adamSync with the parameter /sync replaced with /fs will perform a full sync which will overwrite any conflicting information in LDS with info from your Active Directory

Adding localized users and groups
With ADAMsync you will create objects in your directory based on the XML settings file.  You may want to augment your directory with entries that only exist in LDS for use cases like the following:

  • I need a CMA user account for a user that is not part of my Active Directory, such as an consultant, partner, or associate - You can add a user into LDS using the steps in the earlier chapter to add local users, along side automatically created users.  Both can co-exist in the same LDS directory
  • I need to group my Active Directory users for importing into CMS, but do not have an appropriate group in AD - You can add a group object in LDS using the steps in the earlier chapter, and then add the userProxy objects that were imported via ADAMsync as members of that group.  You can then use the memberOf attribute when importing users in CMS to automatically select users you have added to that group, while they still authenticate using the password from Active Directory
Adding these additional users and groups are done the same way as outlined in the previous chapter and can be done via ADSI Edit or ldif files.

Configure CMS for proxied authentication
Configuring CMS with this directory follows the same principles as configuring with Active Directory but with the following items of note

  • Unlike ActiveDirectory, authenticated users do not have read access to the LDS directory by default.  Only users added to the Reader or Administrator roles in LDS will be suitable for the service user for CMS LDAP settings.  This guide instructed you to create a local LDS user object to use as the service user, and that should be the user configured in CMS
  • The LDAP server settings must be configured to use port 636 when using proxied authentication - the LDS server will not authenticate users if not using SSL
  • Remember that your CMS user import must be sync’d for updates in LDS to propogate to CMS.  So when considering your change management and synchronization, changes should be made in AD, then LDS, and then have CMS sync.  Password changes do not require syncs.
  • The root of user’s DN’s will be the root of your LDS domain (dc=cms,dc=lab in this example), not your original Active Directory domain.  Remember this when constructing LDAP filters and LDAP mappings.  So if your LDS server with DN equals dc=cms,dc=lab is importing the user CN=Bob Smith,CN=Users,DC=company,DC=com  the user will be represented with a different DN, CN=Bob Smith,CN=Users,DC=cms,DC=lab in the LDS directory that CMS will be querying.  NOTE: This will not change the names users log in with, because the user logs in with their XMPP ID, not their DN, but be aware when writing your LDAP import settings.
  • When designing LDAP filters for CMS, you will be targeting classes user and userProxy.  Make sure your filter captures the ldap objects you intend.  For instance, beware objectClass=person does NOT include userProxy objects.

Validate total solution

  • Pick a user from your Active Directory to test with that you know the user account’s password.
  • Confirm the user is listed in the User List in the CMS webAdmin page and note the user’s XMPP ID
  • Using either the CMA client, or the webbridge, log in using the user’s XMPP ID and Active Directory password.  User should authenticate and login