can't connect to remote grid server with ldap user

[thierrycz]

i can connect from a linux client to a grid server under linux too, and it work fine when i use an internal account to authenticate to the object spawner. here is my configuration.

SAS_config_names   = ['iomlinux']

iomlinux = {'java'      : '/usr/bin/java',
            'iomhost'   : ['zzzz.yyyy.xxx.intra'],
            'iomport'   : nnnn,
            'authkey'   : 'mykey2',
            'appserver' : 'SASApp - Workspace Server'
            }

and the .authinfo

mykey2 user user1@saspw password userpass1

But when i try to use the same ldap user, i provide to sas eg to connect to the same grid,

mykey3 user user1@ldapdomain password userpassldap

i get an authentication error.

import saspy sas = saspy.SASsession()

Using SAS Config named: iomlinux We failed in getConnection The application could not log on to the server "zzzz.yyyy.xxxx.intra:nnnnn". The user ID "user1@ldapdomain" or the password is incorrect.

SAS process has terminated unexpectedly. Pid State= (480, 64000) Traceback (most recent call last): File "gosas.py", line 2, in sas = saspy.SASsession() File "/home/th/saspy/lib/python3.8/site-packages/saspy/sasbase.py", line 593, in init self._io = SASsessionIOM(sascfgname=self.sascfg.name, sb=self, **kwargs) File "/home/th/saspy/lib/python3.8/site-packages/saspy/sasioiom.py", line 300, in init self._startsas() File "/home/th/saspy/lib/python3.8/site-packages/saspy/sasioiom.py", line 556, in _startsas ll = self.submit("options svgtitle='svgtitle'; options validvarname=any validmemname=extend pagesize=max nosyntaxcheck; ods graphics on;", "text") File "/home/th/saspy/lib/python3.8/site-packages/saspy/sasioiom.py", line 963, in submit raise SASIOConnectionTerminated(Exception) saspy.sasexceptions.SASIOConnectionTerminated: No SAS process attached. SAS process has terminated unexpectedly. <class 'Exception'>

in the object spawner log in get a reject on my connect, and nothing in the metdataserver log.

2024-03-14T09:15:00,271 INFO [00009761] :xsasii - Access denied. 2024-03-14T09:15:00,272 WARN [00009761] :xsasii - New client connection (42) rejected from server port nnnnn for user user1@ldapdomain. Peer IP address and port are [::ffff:xxx.xxx.xxx.xxx]:63837 for APPNAME=SASPy. 2024-03-14T09:15:00,272 INFO [00009761] :xsasii - Client connection 42 closed.

i wonder if in need to add a parameter to the object spawner to know about the ldap provider. In the doc it seems only possible on metadata server an olap server.

[tomweber-sas]

If this is the right page of doc for what you're doing, it sounds like what you're saying, then it appears it's not supported. https://go.documentation.sas.com/doc/en/bicdc/9.4/bisecag/p1k1qcvnbfsy0en1lzbiztlgt264.htm

Limits 
- Not an alternative to storing user IDs in the metadata (that requirement applies to all configurations).
- Not supported for workspace servers or stored process servers.
- Might involve appending a special qualifier to user IDs that are stored in the metadata.

Is this the issue? SASPy doesn't connect to the metadata server, so I'm not sure about how It's working for EG. EG may be using those credentials to connect to the Metadata Server and then something else to connect to the Workspace server (maybe Token Auth?).

But this doesn't seem something that can be changed via saspy. If the creds don't work for the Workspace server, it won't be able to connect.

Is this the problem?

Thanks, Tom

[thierrycz]

I understand that Saspy doesn't connect directly to the metadata server, and that we can't add ldap support to the object spanwer. What i didn't get, is why the object spawner can authenticate a user stored in the metadata server with his internal account ( user@saspw ), but not with an ldap account also declared in this user. It seems that the spawner has the ability to talk to the metadata server but only to authenticate internal account. It must be by design, i just wanted a confirmation, and that i'm not missing something.

Thanks.

[tomweber-sas]

I can't answer that for sure, not as to why it's like that. But it does appear to be the case. It's documented and you've empirically validated it :)

[thierrycz]

thank you, i will open a case to support to be sure.