Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
46
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 11, 2023, 12:30:20 PM »
Thanks again, Sean.
I've been going through several possibilities:
1. Just create my own derived methods in all apps
2. Edit NetLDAP for my own use since it rarely changes
3. See whether I can persuade Bruce to incorporate my NetLDAP changes, assuming they don't break anyone else's code.
To explore the latter possibility, could you email me an address I could use to send my revisions for testing... to see whether they break your stuff? I don't know whether Bruce would be OK with my posting his entire NetLDAP.clw file in a zip file on a public site like this.
Thanks,
Jane
I've been going through several possibilities:
1. Just create my own derived methods in all apps
2. Edit NetLDAP for my own use since it rarely changes
3. See whether I can persuade Bruce to incorporate my NetLDAP changes, assuming they don't break anyone else's code.
To explore the latter possibility, could you email me an address I could use to send my revisions for testing... to see whether they break your stuff? I don't know whether Bruce would be OK with my posting his entire NetLDAP.clw file in a zip file on a public site like this.
Thanks,
Jane
47
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 09, 2023, 01:59:11 PM »
Pre-fiddling is good, Sean. Sometimes very good 
How much of the NetLdap code is you, Bruce, someone else?
Fortunately, all the methods are virtual so it's easy to override them in procedures. I would find it useful to have one additional string added to LDAPParametersGroupType ( a string(500) for distinguished name) but can live without it.
But is it you or Bruce who vets this code?
I've got code now that so far seems to deal with the various permutations of the different-domain-UPN without breaking same-domain-UPN or plain name or domain\name formats.
My overrides are
1. NetLDAP.SetDomain (still need to work on making this more generic)
2. NetLDAP.SetUser (ditto)
3. NetLDAP.SetAuthUser - I think this is now a generic replacement for the shipping procedure.
I'll post my stuff when I've massaged it a bit more - probably in a couple of days.
Again, thanks for the input.
Cheers,
Jane
How much of the NetLdap code is you, Bruce, someone else?
Fortunately, all the methods are virtual so it's easy to override them in procedures. I would find it useful to have one additional string added to LDAPParametersGroupType ( a string(500) for distinguished name) but can live without it.
But is it you or Bruce who vets this code?
I've got code now that so far seems to deal with the various permutations of the different-domain-UPN without breaking same-domain-UPN or plain name or domain\name formats.
My overrides are
1. NetLDAP.SetDomain (still need to work on making this more generic)
2. NetLDAP.SetUser (ditto)
3. NetLDAP.SetAuthUser - I think this is now a generic replacement for the shipping procedure.
I'll post my stuff when I've massaged it a bit more - probably in a couple of days.
Again, thanks for the input.
Cheers,
Jane
48
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 08, 2023, 09:01:03 AM »Quote
IF NOT INSTRING('\',parms.pAuthUser) AND NOT INSTRING('@',parms.pAuthUser)Where are you finding that code, Sean?
parms.pAuthUser = CLIP(Config:Logon:Domain) & '\' & parms.pAuthUser
END
Now that's very old and may not be needed as such anymore, but it works, so I'm not touching it!
That is fine and solid - assuming that the Active Directory forest only has one domain (Config:Logon:Domain). Which is the case with my client.
That's similar to line 592 in NetLDAP.SetAuthUser.
The code that has changed - removing self.LoginDomain but leaving the extraneous backslash, is in NetLDAP.SetUser (not SetAuthUser).
The LdapDemo app checks group membership for pUser, not pAuthUser. NetLDAP.UserInGroup uses self.user, not selfAuthUser.
My new situation may seem strange, but may become more common.
The AD domain uses a .LOCAL suffix. The client needs to switch user logins to an actual owned domain for some kind of AD-integrated cloud-based single-sign-on service for compatibility with third-party cloud-based apps.
I have figured out how to make this domain mismatch work in my situation. (Multiple possibilities, listed below.)
But I don't want to code it that way if it might be better to fix NetLDAP.clw. (In case this client is not the only one for whom the mixed-domain-name situation will ever show up).
Illustration:
In the first pic, I've set up my domain to support two UPNs in addition to the domain default (which is beach.test).
The second pic shows running an attributes query in the LdapDemo app for Suzi@janefleming.com who is actually a user in the beach.test domain.
Third pic shows the UserInGroup call from the LdapDemo app. On the first pass through, it correctly has the beach.test AD domain name.
But in order to fetch the distinguished name it resets self.domain by fetching the (bogus/arbitrary) domain suffix from the user being checked.
In the second part of the recursion, it uses that incorrect dc=janefleming,dc=com in the call to Active Directory and throws an error. (Third pic).
I have multiple ways to fix it that work for me.
1. Override NetLDAP.SetDomain so it returns based on Config:Logon:Domain.
2. Make my own call to search attributes for the distinguished name BEFORE doing the InGroup. That avoids the recursion which avoids the wrong domain name being set in NetLdap.SetDomain.
This second choice also has some slight speed improvements in one of my apps that checks 5 different group memberships as part of the login. I can code so I only need to look up the distinguished name once and use that for all 5 domain-membership lookups.
Again, don't know whether anyone wants to modify NetLDAP for this. I'm fine coding my own workarounds now that I understand the issue.
But the extraneous backslash in NetLDAP.SetUser is definitely a bug that isn't valid for anybody's situation, as far as I can tell.
Cheers,
Jane
49
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 07, 2023, 09:31:49 AM »Quote
I'll have to digest the rest tomorrowSorry for the long rant, Sean.
TL;DR
I think your client situation sounds like
sAMAccountName = jane
windows2000 = myAdDomain\jane
UPN = jfleming@myAdDomain.local (Same domain, different user name)
whereas my new situation is
sAMAccountName = jane
windows2000 = myAdDomain\jane
UPN = jane@myEmailDomain.com (Different domain that does not match an actual AD domain, same user name)
Quote
Yep, I will confirm you're the lucky one.Yes, I'm truly special
Cheers,
Jane
50
Web Server - Ask For Help / Re: NetLDAP bug in SetUser procedure
« on: May 06, 2023, 04:53:55 PM »
Thanks for confirming, Sean.
Up until now, all our UPNs have been default - matching the Active Directory domain name.
We're confronting needing to change our AD logins to jane@theEmailDomain.com rather than jane@theADdomain.local for some kind of integrated SSO security system our IT is looking at adopting.
I've changed my UPN to the proposed domain name (jane@theEmailDomain.com) and done some experimenting.
On an existing NetTalk app, I was not able to log in and get group membership when using
jane
theADdomain\jane
jane@theEmailDomain.com
Problems I found:
1. The backslash issue. Thanks for confirming that that's not intended. That was making theADdomain\jane fail.
2. Login default -
NetLDAP.Start sets self.DomainType = NetLDAP:UserPrincipalName
So for a login that I (and most of our users) typically do with just the sAMAccountName
jane
NetLDAP.SetUser uses self.DomainType , which means I have become jane@theADdomain.local (rather than the correct UPN that is set in AD).
NetLDAP.SetAuthUser ignores selfDomainType and hard codes it to NetLDAP:UserPrincipalName (i.e., jane@theADdomain.local)
In the 20+ years I've worked on AD networks I haven't been part of one where the UPN didn't match the AD domain name until now. (Lucky me.)
What I've discovered about UPNs is
a. The UPN specified for the user is primary. (In my case, jane@theEmailDomain.com )
b. BUT the default UPN (jane@theADdomain.local)
WILL also work for user login
WILL NOT work to look up group memberships or attributes
c. So having NetLDAP set the UPN to jane@theADdomain.local for a simple 'jane' login bolloxes things.
Basic login works because of the implicit UPN
Group lookups do not work.
For the plain 'jane' login I can compensate by putting
net.domainType = NetLDAP:sAMAccountName
before calling net.UserInGroup()
(I think this problem of defaulting to NetLDAP:UserPrincipalName is actually my doing. In discussing with Bruce years ago the various login names users can enter I think I suggested defaulting to creating a UPN. Shame on me... sigh...)
3. NetLDAP.Search is out to get me. (Actually, UserInGroup when pActiveDirectory is set to TRUE)
The ActiveDirectory_UserInGroup procedure in the LDAP demo calls net.SetDomain()
So when I use jane@theEmailDomain.com, net.SetDomain helpfully splits that into dc=theEmailDomain,dc=com
This domain does not exist in Active Directory.
If pActiveDirectory is TRUE, then what is produced from NetLDAP.UserInGroup() is
pFilter=(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN=Jane Fleming,OU=SysAdmin Users,OU=CHC SysAdmin,DC=theAdDomain,DC=local)) -- which is correct.
BUT the pBase parm fed into NetLDAP.Search is dc=theEmailDomain,dc=com
WHICH IS WRONG because that domain does not exist in AD.
If I manually look up the DistinguishedName and set that before calling net.UserInGroup(), then the recursive call (which sets the incorrect domain name) doesn't happen and I'm good.
So I think I can code around all my issues in my calling procedures (except for the extraneous backslash - which I edited in NetLDAP.clw.) I made a dedicated proc to get the DN before calling UserInGroup.
Or I might try just overriding NetLDAP.SetDomain so that it always uses the domain being used by AuthUser.
And I'm guessing that not a lot of people will be using a different UPN suffix in Active Directory situations. But perhaps good to be aware of the challenges in case anybody else goes that route.
Thanks for your input, Sean!
Cheers,
Jane
Up until now, all our UPNs have been default - matching the Active Directory domain name.
We're confronting needing to change our AD logins to jane@theEmailDomain.com rather than jane@theADdomain.local for some kind of integrated SSO security system our IT is looking at adopting.
I've changed my UPN to the proposed domain name (jane@theEmailDomain.com) and done some experimenting.
On an existing NetTalk app, I was not able to log in and get group membership when using
jane
theADdomain\jane
jane@theEmailDomain.com
Problems I found:
1. The backslash issue. Thanks for confirming that that's not intended. That was making theADdomain\jane fail.
2. Login default -
NetLDAP.Start sets self.DomainType = NetLDAP:UserPrincipalName
So for a login that I (and most of our users) typically do with just the sAMAccountName
jane
NetLDAP.SetUser uses self.DomainType , which means I have become jane@theADdomain.local (rather than the correct UPN that is set in AD).
NetLDAP.SetAuthUser ignores selfDomainType and hard codes it to NetLDAP:UserPrincipalName (i.e., jane@theADdomain.local)
In the 20+ years I've worked on AD networks I haven't been part of one where the UPN didn't match the AD domain name until now. (Lucky me.)
What I've discovered about UPNs is
a. The UPN specified for the user is primary. (In my case, jane@theEmailDomain.com )
b. BUT the default UPN (jane@theADdomain.local)
WILL also work for user login
WILL NOT work to look up group memberships or attributes
c. So having NetLDAP set the UPN to jane@theADdomain.local for a simple 'jane' login bolloxes things.
Basic login works because of the implicit UPN
Group lookups do not work.
For the plain 'jane' login I can compensate by putting
net.domainType = NetLDAP:sAMAccountName
before calling net.UserInGroup()
(I think this problem of defaulting to NetLDAP:UserPrincipalName is actually my doing. In discussing with Bruce years ago the various login names users can enter I think I suggested defaulting to creating a UPN. Shame on me... sigh...)
3. NetLDAP.Search is out to get me. (Actually, UserInGroup when pActiveDirectory is set to TRUE)
The ActiveDirectory_UserInGroup procedure in the LDAP demo calls net.SetDomain()
So when I use jane@theEmailDomain.com, net.SetDomain helpfully splits that into dc=theEmailDomain,dc=com
This domain does not exist in Active Directory.
If pActiveDirectory is TRUE, then what is produced from NetLDAP.UserInGroup() is
pFilter=(&(objectClass=group)(member:1.2.840.113556.1.4.1941:=CN=Jane Fleming,OU=SysAdmin Users,OU=CHC SysAdmin,DC=theAdDomain,DC=local)) -- which is correct.
BUT the pBase parm fed into NetLDAP.Search is dc=theEmailDomain,dc=com
WHICH IS WRONG because that domain does not exist in AD.
If I manually look up the DistinguishedName and set that before calling net.UserInGroup(), then the recursive call (which sets the incorrect domain name) doesn't happen and I'm good.
So I think I can code around all my issues in my calling procedures (except for the extraneous backslash - which I edited in NetLDAP.clw.) I made a dedicated proc to get the DN before calling UserInGroup.
Or I might try just overriding NetLDAP.SetDomain so that it always uses the domain being used by AuthUser.
And I'm guessing that not a lot of people will be using a different UPN suffix in Active Directory situations. But perhaps good to be aware of the challenges in case anybody else goes that route.
Thanks for your input, Sean!
Cheers,
Jane
51
Web Server - Ask For Help / NetLDAP bug in SetUser procedure
« on: May 05, 2023, 12:54:54 PM »
Bruce,
There's a bug in the NetLDAP.SetUser() procedure when the user name is of the format DOMAIN\Jane.Bean
SetUser is called multiple times by NetLdap.UserInGroup().
The first time through, it correctly strips off the domain and backslash and returns
sAMAccountName=Jane.Bean
After the first time, however, it hits the ELSE clause and adds a backslash.
This results in
sAMAccountName=\Jane.Bean
And the group lookup fails.
There's a comment on line 624 where the extraneous backslash is injected.
I don't know when the change was made to NetLDAP, but was testing something yesterday and discovered that this is broken.
That backslash needs to be not inserted.
NT 12.59.
jf
There's a bug in the NetLDAP.SetUser() procedure when the user name is of the format DOMAIN\Jane.Bean
SetUser is called multiple times by NetLdap.UserInGroup().
The first time through, it correctly strips off the domain and backslash and returns
sAMAccountName=Jane.Bean
After the first time, however, it hits the ELSE clause and adds a backslash.
This results in
sAMAccountName=\Jane.Bean
And the group lookup fails.
There's a comment on line 624 where the extraneous backslash is injected.
I don't know when the change was made to NetLDAP, but was testing something yesterday and discovered that this is broken.
That backslash needs to be not inserted.
NT 12.59.
jf
52
Web Server - Ask For Help / Re: OT - Are the SV newsgroups still alive?
« on: March 20, 2023, 11:13:07 AM »
If you use Thunderbird for the newsgroups, read this:
https://clarionhub.com/t/softvelocity-newsgroup-not-working-thunderbird-setting-change-required/5293
https://clarionhub.com/t/softvelocity-newsgroup-not-working-thunderbird-setting-change-required/5293
53
Web Server - Ask For Help / Re: Change a static page
« on: March 20, 2023, 11:02:22 AM »
You can also opt to keep the cache on and manually clear it when you change something static - either with the button on the web server (if it's not running as a service and is visible) or with the magic URL.
54
Web Server - Ask For Help / Re: NT12.55 NetDemo Compile Error
« on: March 06, 2023, 09:41:39 AM »
It's getting filled in by a new default in the "Use NetTalk Send Email Controls" template.
You can go into that extension template on the TestEmailSendControlTemplate procedure in the demo program and delete the value for the "OAuth Token" field.
You can go into that extension template on the TestEmailSendControlTemplate procedure in the demo program and delete the value for the "OAuth Token" field.
55
Web Server - Ask For Help / Any SAML wisdom out there?
« on: March 01, 2023, 04:01:07 PM »
Anybody integrated a SAML provider with NetTalk ?
Okta? MS Azure AD? Others?
Any wisdom? Any war stories?
Okta? MS Azure AD? Others?
Any wisdom? Any war stories?
56
Web Server - Ask For Help / Re: Draw (Graph) crashes my web server
« on: February 10, 2023, 01:06:10 PM »
For now modifying the code in draw.clw seems like the way to go.
Sounds good. Draw doesn't get updated very often.
I made a copy for this app and changed one line of code in draw.clw. Works fine.
Thanks, Bruce.
Jane
57
Web Server - Ask For Help / Draw (Graph) crashes my web server
« on: February 09, 2023, 02:52:55 PM »
Subtitle - is there a way I'm missing to override Draw's drwGetTempPath?
It's presently calling GetTempPathA.
I added a graph to a nettalk app, copying one of the examples.
Works fine on my development machine.
Works fine on server when running as a service or run asAdministrator.
Crashes on server when not running as a service when I run the graph procedure. Error (shown in pic) says it's trying to create DrawStore.tmp in a folder that does not exist.
Yes, the app is mostly running as a service. And then it runs fine (using the windows\temp folder).
Or I can manifest the app with a requireAdministrator manifest and it works running as an exe on the server. But then I have to click through the UAC popup on my dev machine each time I compile and run.
It may just be that something is bolluxed on the server. SET says "my" temp path ends with \6
But that folder doesn't exist.
The GUI says my user's temp path just ends with \temp.
But this all seems rather fragile. It would be nice to have an option to tell Draw where to do its thing and not to encounter some servers where it can't make its temp folder work.
(Until, of course, NT 14's javascript graphs!)
Cheers,
Jane, writer of hyperbolic subject lines
It's presently calling GetTempPathA.
I added a graph to a nettalk app, copying one of the examples.
Works fine on my development machine.
Works fine on server when running as a service or run asAdministrator.
Crashes on server when not running as a service when I run the graph procedure. Error (shown in pic) says it's trying to create DrawStore.tmp in a folder that does not exist.
Yes, the app is mostly running as a service. And then it runs fine (using the windows\temp folder).
Or I can manifest the app with a requireAdministrator manifest and it works running as an exe on the server. But then I have to click through the UAC popup on my dev machine each time I compile and run.
It may just be that something is bolluxed on the server. SET says "my" temp path ends with \6
But that folder doesn't exist.
The GUI says my user's temp path just ends with \temp.
But this all seems rather fragile. It would be nice to have an option to tell Draw where to do its thing and not to encounter some servers where it can't make its temp folder work.
(Until, of course, NT 14's javascript graphs!)
Cheers,
Jane, writer of hyperbolic subject lines
58
Web Server - Ask For Help / Re: open submenu indented?
« on: January 14, 2023, 11:41:42 AM »
If you're trying to do what's shown in the first pic, Sean, what I've found works is to set each of the "calling" menu items to open to the right (second pic).
jf
jf
60
Web Server - Ask For Help / Hiding password (etc) in web server log
« on: December 24, 2022, 06:56:40 PM »
Grinchly Greetings, Obi Wan!
I was interested in the solution you worked out for masking passwords in the web server log display during this week's webinar.
What you showed mostly works.
BUT? it still leaks passwords BEFORE they get to the AddLog section of code.
As soon as you move around in the log and then come back to the POST, the value has been masked by the code you added in AddLog. But initially it displays on the screen.
If there were an embed available in StartNewThread, before the ?web:LastPost is first displayed, that initial display of sensitive data could be avoided.
[Edited to add - would you add an embed before that DISPLAY statement ? ]
Of course, that requires running the filtering code twice
Holiday Cheers,
Jane
I was interested in the solution you worked out for masking passwords in the web server log display during this week's webinar.
What you showed mostly works.
BUT? it still leaks passwords BEFORE they get to the AddLog section of code.
As soon as you move around in the log and then come back to the POST, the value has been masked by the code you added in AddLog. But initially it displays on the screen.
If there were an embed available in StartNewThread, before the ?web:LastPost is first displayed, that initial display of sensitive data could be avoided.
[Edited to add - would you add an embed before that DISPLAY statement ? ]
Of course, that requires running the filtering code twice
Holiday Cheers,
Jane