I think you have your answer now, but my thoughts are that ideally your consultant would have set up 2 imports - one from AD into the end user object in LDSD and the other into the analyst object. Usually for AD an LDAP filter is used on the import to make sure only analysts in AD get imported into the analyst area of LDSD and end users into end users. You will get the occasional blip where someone is moved from one to the other, but it should be fairly bullet proof.
It can be tedious mapping what look to to be the same fields each time, but it pays to set this up.
Ideally (again) when someone gets taken on, the user taken process puts the person into the correct bit of AD and they get created as an analyst. However there are plenty of times when this doesn't happen and you then have to manually 'promote' the newly created end user to an analyst, but then you then also have to mark them in whatever way has been done in AD so they are seen as an analyst from that point onwards.
Especially in University environments this process can cycle round a few times as people move from being staff to student or sometimes event both at the same time, so it does need some thought to get it bullet proof. If you truly want it to be totally bullet proof, I'd look at using MAP to interface to your source of users and allow it to follow a MAP process to create users in LDSD and highlight any transgressions it finds.