Highlighted
Honored Contributor.
Honored Contributor.

Re: Catching Illegal UPN Value in AD Driver

dgersic;2493014 wrote:
Thinking about it, I'm not sure that you can do it with heartbeat. That'd be on the publisher, and I don't know if you can get a psexecute to work from a publisher policy. Might have to use a trigger job to kick it off instead. If you can get it to return anything. psexecute is kinda fire and forget. Maybe an LDAP query against the domain to get the same thing(s).

If you can post the output from that powershell script, I'd be curious to see what you get back.


I tried it. I can't post the actual output from the customer, but it is just a list of alternate UPN suffixes. It doesn't seem to show the primary though.

My lab domain is ad.milford.weisberg.net, but here is the output when I ran it on my domain:

PS C:\Users\Administrator\Desktop> Get-adforest | select UPNSuffixes -ExpandProperty UPNSuffixes
samlexperts.com
weisberg.co
PS C:\Users\Administrator\Desktop>


Again, It only shows the ALTERNATIVE domain suffixes, not the primary one (in my case, ad.milford.weisberg.net). I have 2 listed, as shown, in my test lab.

This particular customer does own the scripting driver, so I could probably just do something with that and a subscriber trigger at a regular interval.

Matt
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver

matt;2493017 wrote:
I tried it. I can't post the actual output from the customer, but it is just a list of alternate UPN suffixes. It doesn't seem to show the primary though.

My lab domain is ad.milford.weisberg.net, but here is the output when I ran it on my domain:

PS C:\Users\Administrator\Desktop> Get-adforest | select UPNSuffixes -ExpandProperty UPNSuffixes
samlexperts.com
weisberg.co
PS C:\Users\Administrator\Desktop>


Again, It only shows the ALTERNATIVE domain suffixes, not the primary one (in my case, ad.milford.weisberg.net). I have 2 listed, as shown, in my test lab.

This particular customer does own the scripting driver, so I could probably just do something with that and a subscriber trigger at a regular interval.

Matt


Interesting, thanks. I was expecting to see it report all allowed values. Having it report only some of them is strange.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver

matt;2493017 wrote:
I tried it. I can't post the actual output from the customer, but it is just a list of alternate UPN suffixes. It doesn't seem to show the primary though.

My lab domain is ad.milford.weisberg.net, but here is the output when I ran it on my domain:

PS C:\Users\Administrator\Desktop> Get-adforest | select UPNSuffixes -ExpandProperty UPNSuffixes
samlexperts.com
weisberg.co
PS C:\Users\Administrator\Desktop>


Again, It only shows the ALTERNATIVE domain suffixes, not the primary one (in my case, ad.milford.weisberg.net). I have 2 listed, as shown, in my test lab.

This particular customer does own the scripting driver, so I could probably just do something with that and a subscriber trigger at a regular interval.

Matt


Poking around a bit, it looks like maybe you can read all "valid" suffix values from the domain object via LDAP. Have a look at msDS-AllowedDNSSuffixes. Multi-valued attribute of strings. Grab the values, reformat in to a mapping table, and boom, you have a "valid domain suffix" checker.

Not sure how useful that would be, but it looks like it could be created with a trigger job to maintain it.
0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver


>
> Again, It only shows the ALTERNATIVE domain suffixes, not the primary
> one (in my case, ad.milford.weisberg.net). I have 2 listed, as shown,
> in my test lab.
>
> This particular customer does own the scripting driver, so I could
> probably just do something with that and a subscriber trigger at a
> regular interval.


Scripting driver would allow this, so that would resolve the PSExecute
not returning data problem.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver

geoffc;2493054 wrote:

>
> Again, It only shows the ALTERNATIVE domain suffixes, not the primary
> one (in my case, ad.milford.weisberg.net). I have 2 listed, as shown,
> in my test lab.
>
> This particular customer does own the scripting driver, so I could
> probably just do something with that and a subscriber trigger at a
> regular interval.


Scripting driver would allow this, so that would resolve the PSExecute
not returning data problem.


You can do it "directly" from AD driver.
This info is "visible" in Application Schema - that mean you can make query to the destination (AD) and store it in your variable.

0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver


> I think you are right actually. I went back to working on this today and
> I did a mapping table like Geoff suggested and that worked fine. But I


So technically, I was correct.

> though it let me write anything I wanted via the IdM driver. So I a
> guess Aaron was right and what I was seeing was something else entirely.


Wow, what is this Aaron stuff? I was the one correct, he is just a
johny come lately on this one. 🙂

Glad to see my memory was correct and they did not change it on the AD
side, but hey, you never know.


0 Likes
Highlighted
Knowledge Partner
Knowledge Partner

Re: Catching Illegal UPN Value in AD Driver


> We'll have to decide how important it is to automate the domain suffix
> list versus just maintaining the mapping table. But based on that simple
> PowerShell command, it may not be that hard.


The problem is that the PSExecute command, which allows the AD driver to
call Powershell commands does not return output. So while you could call
it, the values will not be returned to the engine, so I am not sure how
helpful that will be.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.