SQL Server Log Shipping – Read Only/Standby Different Users

You can't change the secondary database in any way.
This is normal - the secondary database is supposed to be a backup of the main database, so it's not possible to add stuff that's not in the main database. That's why it's in read-only mode.

It's fine to use the secondary database for reporting, to reduce the load on the primary server (see Using Secondary Servers for Query Processing).
But if you need any special indices for that, you have to add them in the primary database and wait until they are log-shipped to the secondary database.

As jchelad already said in his answer, one disadvantage of using the secondary database for reporting is that users are disconnected whenever a log backup is restored.
It's possible to change this, so that restoring is paused until nobody is connected to the database.

Quote from the above link:

There are two options for configuration when you place the secondary database in standby mode:

• You can choose to have database users disconnected when transaction log backups are being restored. If you choose this option, users will be disconnected from the database each time the log shipping restore job attempts to restore a transaction log to the secondary database. Disconnection will happen on the schedule you set for the restore job.

• You can choose not to disconnect users. In this case, the restore job cannot restore transaction log backups to the secondary database if there are users connected to that database. Transaction log backups will accumulate until there are no user connections to the database.

But I wouldn't recommend using the second option.
We are using logshipping at work, and we are using the secondary database for reporting.

We decided to choose the first option (users are disconnected when a backup is restored) because having a backup is more important than being able to run queries all the time.

We didn't like the second option (only restore if no one is connected to the database) because in case the main server dies, we don't want to find out that the secondary database wasn't restored in the last few hours because the salespeople have been running queries all day.

We "educated" our reporting users that there is a short time every 15 minutes where they can't run queries, and they accept that.
(the alternative would be to run the queries on a copy of the main database from yesterday evening, but they prefer data from today, so they have to live with the "15 minute break")

The trick is to avoid the orphaned logins in the first place, not to synchronize them afterwards.

As you probably know, 'orphaned' users are due to the SID associated with the user in the database not matching the SID associated with the login on the server. When a login is created on a server, the value for the SID is either taken from Active Directory (if you are using "integrated" or "windows" logins) or generated by SQL Server (in the case of SQL logins). With SQL Server logins, the value of the SID is generated by SQL Server. The value will vary each time you create a login [hint] unless you take special care.

IOW, if you create a login named "foo" on two servers, each login will have a different SID value. If you create a login named "foo", drop it and create it again, each occurrence of "foo" will have a different SID value.

Strategy #1: use integrated security

With Integrated security, the SID used by SQL Server for the login on the server and the user in the database is taken from the Active Directory login. Because of that, the values can't differ. Changing from SQL logins to integrated logins is usually a hassle, developers generally don't like to spend time on infrastructure work and it's probably a non-starter.

Strategy #2: use the "SID" parameter when creating logins on the destination server.

If you create a login using TSQL code, you can specify a specific value for a SID. You can construct a set of CREATE LOGIN statements (including SIDs and exported passwords) so that the SIDs match on both servers. That way, when you restore the database (via shipped log backups or any other way), the SIDs will match and people can get to the data.

Microsoft provides code that will help you create these CREATE LOGIN statements based on what exists in the source server. You can then copypaste those statements over to the destination server and run them. The name of the procedure is sp_help_revlogin. The code varies slightly between SQL Server versions, but the version for SQL2008R2 is available from Microsoft here

TLDR: I'd recommend using sp_help_revlogin on the source server to create new CREATE LOGIN statements for the logins that have to sync up. (You don't need to do every login, just the ones that have problems.) Then, use those statements to drop and recreate the logins on the destination server. Since you will be dropping logins, you should be aware of any database permissions that those logins already have (maybe there are other databases on the destination server that the developers already have permissions in?) and you should be able to recreate those permissions after you get the login recreated.