User Folders cannot be created or retrieved if connected user ID is not a person identity.

[Yordan]

Hello,

I am looking for explanation and possible solution of the following error messages recorded in SASMeta log:

******@****** - User Folders cannot be created or retrieved if connected user ID is not a person identity.  Must be connected as a person identity or valid person name must be passed in request.
INFO  ******@****** - GetUserFolders return code=807fec9f....
INFO  ******@****** - DoRequest return code=807fec9f....
ERROR ******@****** - User Folders cannot be created or retrieved if connected user ID is not a person identity.  Must be connected as a person identity or valid person name must be passed in request

I know when it started. It started when we stopped access to SAS 9.3 for some of the users and gave them access to SAS 9.4.
These messages are generated in SASMeta log of 9.3 since that day.

I have tried several times to reproduce it on my own but I cannot.
What is the origin and how can I stop it?

Thanks in advance

[nhvdwalt]

It looks like SAS is not able to map the userid to a person object. Check the accounts tab for the user and ensure that the ID they log on with appears there. In other words, the userid and password authenticates ok, but SAS doesnt know who it is since there is no mapping.

[PaulHomes]

I thought perhaps it might be because the userid for the credentials being used to log into the SAS Metadata Server are on a group rather than a user (Person object). This is similar to how you see sassrv on the SAS General Servers groups Accounts tab and can login as the group using the sassrv credentials. I created a SAS metadata group 'Test' and added a users login (demotest) to its Accounts tab, then logged in as that user. I see the following in the SAS Metadata Server log:

2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - The specified person name 'Test' does not exist in metadata.
2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - GetUserFolders return code=807feca2....
2017-10-22T08:29:23,094 INFO [00097723] 2448:demotest - DoRequest return code=807feca2....

So similar but not identical. I did this test with sas 9.3 M2 - which SAS 9.3 version are you using?

[PaulHomes]

Also, what method did you use to stop access to SAS 9.3 for your users?

[Yordan]

Hi PaulHomes,

I removed the specified Active Directory groups from user sync script. That`s the way I stopped access.

Yes, your simulation looks similar to my errors. Unfortunately, I checked all available groups in SAS Meta and there is no sign of users which generate error messages.
The other thing I forgot to mention, access was forbidden on test and prod environment simultaneously. There are no error messages in test metadata server log.
Other interesting point is that error messages are generated only during active business hours and I do not see any sign of scheduled job too. Time and userid are different each day.

[PaulHomes]

Does the client IP address in the SAS metadata server log for the connection give you some clues about the server/workstation the connection is coming from?

[Yordan]

No, at all.

But I noticed something. I decided to check Client connection tab of Metadata Server on Management console. Here is why I found out.

There are connection for the users which generates error messages. Obviously, error messages are generated when they connect to the Meta Server because time of error and connection is exactly the same. So, probably the reason for errors is the following: users are not in User Manager but they are still trying/able to connect to Metadata Server. When they connect to Metadata server, this leads to respective error messages because there are no identity.

Why they are able to connect to it and how could I prevent it? Any ideas?

[PaulHomes · Accepted solution]

If you have removed the users from metadata (via the AD sync script), but they can still present valid credentials to the SAS metadata server, then they will be considered to have logged in as the PUBLIC group. Normally the Foundation repository ACT (commonly named Default ACT) prevents PUBLIC-only users from logging on because of the permission denials to PUBLIC. Is there any chance your repository ACT has been modified such that PUBLIC has granted RM to allow PUBLIC-only logins? Check the Permission Pattern tab and, if so, deny all permissions to PUBLIC to block access to PUBLIC-only users (assuming you have no business reasons to allow it).

Also confirm that you do indeed have a repository ACT. If there is no repository ACT then permissions are granted by default (unless otherwise denied elsewhere). You will notice the presence of a repository ACT in the SAS Management Console Authorization Manager because it has a slightly different icon (with a small blue cylinder on it).

[Yordan]

I think I am on the right way following your important advices.

Yes, I know how it is look like repository ACT and there is no repository ACT on this installation.
Is there any way to find out where these logging on permissions come from?
I notice bizarre situation on SAS admin ACT - PUBLIC group has Metadata_Read permissions on Authorization tab. Could it be the cause?
No idea why it is configured this way. I was not involved during installation and initial configuration process. Could it be the root cause?

[PaulHomes]

If you don't have a repository ACT then permissions are granted by default unless otherwise specified. Your (probably grey/indirect) RM grant to PUBLIC on "SAS Administrator Settings" ACT Authorization tab is most likely due to your lack of a repository ACT. If I turn off the repository ACT in my lab environment that is what I see (and PUBLIC-only users are then allowed to login).

Unless there is a very specific and good reason to have no repository ACT (unlikely) then I would suggest you review any existing Default ACT and make it your repository ACT, or (re)create Default ACT from the information in the documentation and make it your repository ACT. 

If you don't have a repository ACT then there way well be other issues with the installation. I would strongly suggest a review - perhaps contact SAS Professional Service or a local SAS Partner for assistance if you need help. However, it sounds like perhaps you are migrating from SAS 9.3 to 9.4 and this 9.3 environment might be retired?

[Yordan]

Hi PaulHomes,

Unfortunately, you are not right. Client do not have any plans for migrating to 9.4. It wants to use both versions simultaneously. So, obviously I have to find any solution. I have no idea why it is configured this way. I am more confused because there is a Default ACT on Test environment and there is not on production env. I strongly hope they have got a good explanation why it is configured initially this way.

I will try to understand client`s reason to run SAS without Default ACT (I doubt someone could explain me). If there is not, I will create ACT similar to Test env ACT. If there is a reason for running without Default ACT, probably error messages will continue to fill my log.

[JuanS_OCS]

@Yordan, careful

On prod there is a Default ACT for sure! Perhaps you don't have access to see that Default ACT, of perhaps another ACT has been set up as default one (right click button on the ACT, there is a checkbox).

[Yordan]

@JuanS_OCS

No, there is no Default ACT or it is not visible neither through my account (which is the most powerful user account on the system) neither through sasadm account.

[JuanS_OCS]

thank you @Yordan.

And, there is any other ACT in Production, marked as default?

[Yordan]

Unfortunately, there is no ACT marked as default.
It is very strange and I am still looking for answers from the client. Maybe there is some good reason to make initial configuration this way but cannot find explanation until now.